Date   

Re: CDI integration

Sergey Beryozkin
 

Sorry for the typo, I meant to say that  "ignoring of the fact that major non-EE containers are *now* thought by"

On 31/05/17 12:19, Sergey Beryozkin wrote:
On 31/05/17 12:09, Arjan Tijms wrote:
On Wed, May 31, 2017 at 04:00 am, Sergey Beryozkin wrote:
JAX-RS is big in EE but it needs to be present in SpringBoot, etc.

Why?

Because this is what non EE users of JAX-RS (and there are many of them) look for (they migrate to Spring Boot and non-EE containers in general).

I've always felt that this ignoring of the fact that major non-EE containers are not thought by many many users is not good, as far as restricting a given (JAX-RS) API is concerned

Cheers, Sergey




Re: CDI integration

Sergey Beryozkin
 

On 31/05/17 12:09, Arjan Tijms wrote:
On Wed, May 31, 2017 at 04:00 am, Sergey Beryozkin wrote:
JAX-RS is big in EE but it needs to be present in SpringBoot, etc.

Why?

Because this is what non EE users of JAX-RS (and there are many of them) look for (they migrate to Spring Boot and non-EE containers in general).

I've always felt that this ignoring of the fact that major non-EE containers are not thought by many many users is not good, as far as restricting a given (JAX-RS) API is concerned

Cheers, Sergey



Re: CDI integration

Sergey Beryozkin
 

On 31/05/17 12:07, Arjan Tijms wrote:


On Wed, May 31, 2017 at 12:53 PM, Sergey Beryozkin <sberyozkin@...> wrote:
Hi

Lest not dramatize it,
difficult, confusing, all because of @Context ?

Yes.

It's another injection and bean model and doesn't play nice with the platform wide services for things such as extensions, decorators and interceptors.

This is also why we deprecated and native managed beans in JSF.

Java EE is not as good as it could be now, because many specs live on their own little islands.



As well as re this 'ownership' claim of JAX-RS by EE.

JAX-RS is a part of Java EE, is it not?
Technically it is. Not all nderstand though why JAX-RS is one of the most popular EE spec today - let me answer, because the developers
could use it everywhere without having to ensure some EE Managed ExecutorService exists around.

Thanks, Sergey

Kind regards,
Arjan Tijms

 

Sergey

On 31/05/17 11:44, Arjan Tijms wrote:
Hi,

On Wed, May 31, 2017 at 11:52 AM, Sergey Beryozkin <sberyozkin@...> wrote:
@Context is that little thing that has helped to make JAX-RS visible outside of the EE world, as opposed to it be yet another EE spec.

It's not just another EE spec, but one of the fundamental EE specs.

 
Rather than trying to keep JAX-RS more and more dependent on EE pieces I'd like to encourage us keeping it as open as possible

IMHO; open as possible also means that you eventually commit to nothing and only make it more difficult and confusing to use in its primary environment. 

Kind regards.
Arjan Tijms



 
Sergey


On 31/05/17 10:44, Sebastian Daschner wrote:

Yes, agreed.

Especially the ability to @Inject JAX-RS managed objects (basically what is @Context today) would be very helpful. That enables to inject UriInfo within the EE application and also getting rid of @Context to streamline Java EE further :-)

Cheers,
Sebastian
   


On 05/31/2017 03:12 PM, Christian Kaltepoth wrote:
I agree with Guillermo and Arjan that further CDI alignment is very important for JAX-RS. 

It would be great to see some EG discussion about this.

Christian

2017-05-25 20:13 GMT+02:00 Arjan Tijms <arjan.tijms@...>:
Hi,

I too would greatly love to see this happening. CDI alignment IMHO should have been -the- major theme of Java EE and unfortunately too few steps have been made towards that goal.

Kind regards,
Arjan Tijms



On Thu, May 25, 2017 at 8:04 PM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,

Time is quickly running out, and I guess what the plans are regarding CDI alignment. There's an open issue [1] labeled as "2.1-candidate" but it seems no work has been done on that yet.

Given the time and resource limits the EG has, I propose to simply add a note to the spec saying that "when running on a Java EE Application Server/when CDI is available, resources and providers MUST be available for CDI extensions to process it, just like if had a CDI bean defining annotation", e.g.: providers and resources are discovered by the CDI runtime like any other bean, but *they don't need to be treated as beans*. That basically ressembled the behaviour offered by trimmed archives on CDI 2.0 [2].

What we gain with that? Users could easily create an extension to make all the resources @RequestScoped, while maintaining the spec clean (further integration would need more discussion). At the moment it's not possible to do that with CDI [3] and you have to mark all your classes as @Dependent (a practice that is not so uncommon [4]) or mark CDI bean discovery "all"/"trimmed".

How do you see it? Do you think it's viable at this time?




--







Re: CDI integration

Arjan Tijms
 

On Wed, May 31, 2017 at 04:00 am, Sergey Beryozkin wrote:
JAX-RS is big in EE but it needs to be present in SpringBoot, etc.

Why?


Re: CDI integration

Arjan Tijms
 



On Wed, May 31, 2017 at 12:53 PM, Sergey Beryozkin <sberyozkin@...> wrote:
Hi

Lest not dramatize it,
difficult, confusing, all because of @Context ?

Yes.

It's another injection and bean model and doesn't play nice with the platform wide services for things such as extensions, decorators and interceptors.

This is also why we deprecated and native managed beans in JSF.

Java EE is not as good as it could be now, because many specs live on their own little islands.



As well as re this 'ownership' claim of JAX-RS by EE.

JAX-RS is a part of Java EE, is it not?

Kind regards,
Arjan Tijms

 

Sergey

On 31/05/17 11:44, Arjan Tijms wrote:
Hi,

On Wed, May 31, 2017 at 11:52 AM, Sergey Beryozkin <sberyozkin@...> wrote:
@Context is that little thing that has helped to make JAX-RS visible outside of the EE world, as opposed to it be yet another EE spec.

It's not just another EE spec, but one of the fundamental EE specs.

 
Rather than trying to keep JAX-RS more and more dependent on EE pieces I'd like to encourage us keeping it as open as possible

IMHO; open as possible also means that you eventually commit to nothing and only make it more difficult and confusing to use in its primary environment. 

Kind regards.
Arjan Tijms



 
Sergey


On 31/05/17 10:44, Sebastian Daschner wrote:

Yes, agreed.

Especially the ability to @Inject JAX-RS managed objects (basically what is @Context today) would be very helpful. That enables to inject UriInfo within the EE application and also getting rid of @Context to streamline Java EE further :-)

Cheers,
Sebastian
   


On 05/31/2017 03:12 PM, Christian Kaltepoth wrote:
I agree with Guillermo and Arjan that further CDI alignment is very important for JAX-RS. 

It would be great to see some EG discussion about this.

Christian

2017-05-25 20:13 GMT+02:00 Arjan Tijms <arjan.tijms@...>:
Hi,

I too would greatly love to see this happening. CDI alignment IMHO should have been -the- major theme of Java EE and unfortunately too few steps have been made towards that goal.

Kind regards,
Arjan Tijms



On Thu, May 25, 2017 at 8:04 PM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,

Time is quickly running out, and I guess what the plans are regarding CDI alignment. There's an open issue [1] labeled as "2.1-candidate" but it seems no work has been done on that yet.

Given the time and resource limits the EG has, I propose to simply add a note to the spec saying that "when running on a Java EE Application Server/when CDI is available, resources and providers MUST be available for CDI extensions to process it, just like if had a CDI bean defining annotation", e.g.: providers and resources are discovered by the CDI runtime like any other bean, but *they don't need to be treated as beans*. That basically ressembled the behaviour offered by trimmed archives on CDI 2.0 [2].

What we gain with that? Users could easily create an extension to make all the resources @RequestScoped, while maintaining the spec clean (further integration would need more discussion). At the moment it's not possible to do that with CDI [3] and you have to mark all your classes as @Dependent (a practice that is not so uncommon [4]) or mark CDI bean discovery "all"/"trimmed".

How do you see it? Do you think it's viable at this time?




--






Re: CDI integration

Sergey Beryozkin
 

Let me step back.
+1 to having a better CDI integration, and in CXF my colleagues work hard on making it better.
@Context needs to be continued to be supported though. JAX-RS is big in EE but it needs to be present in SpringBoot, etc.
Wiring CDI into non EE can become problematic thus continuing to have a basic @Context support is good.

Sorry for hajacking the thread

Cheers, Sergey

On 31/05/17 11:53, Sergey Beryozkin wrote:
Hi

Lest not dramatize it,
difficult, confusing, all because of @Context ? I'm not going to comment.

As well as re this 'ownership' claim of JAX-RS by EE.

Sergey
On 31/05/17 11:44, Arjan Tijms wrote:
Hi,

On Wed, May 31, 2017 at 11:52 AM, Sergey Beryozkin <sberyozkin@...> wrote:
@Context is that little thing that has helped to make JAX-RS visible outside of the EE world, as opposed to it be yet another EE spec.

It's not just another EE spec, but one of the fundamental EE specs.

 
Rather than trying to keep JAX-RS more and more dependent on EE pieces I'd like to encourage us keeping it as open as possible

IMHO; open as possible also means that you eventually commit to nothing and only make it more difficult and confusing to use in its primary environment. 

Kind regards.
Arjan Tijms



 
Sergey


On 31/05/17 10:44, Sebastian Daschner wrote:

Yes, agreed.

Especially the ability to @Inject JAX-RS managed objects (basically what is @Context today) would be very helpful. That enables to inject UriInfo within the EE application and also getting rid of @Context to streamline Java EE further :-)

Cheers,
Sebastian
   


On 05/31/2017 03:12 PM, Christian Kaltepoth wrote:
I agree with Guillermo and Arjan that further CDI alignment is very important for JAX-RS. 

It would be great to see some EG discussion about this.

Christian

2017-05-25 20:13 GMT+02:00 Arjan Tijms <arjan.tijms@...>:
Hi,

I too would greatly love to see this happening. CDI alignment IMHO should have been -the- major theme of Java EE and unfortunately too few steps have been made towards that goal.

Kind regards,
Arjan Tijms



On Thu, May 25, 2017 at 8:04 PM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,

Time is quickly running out, and I guess what the plans are regarding CDI alignment. There's an open issue [1] labeled as "2.1-candidate" but it seems no work has been done on that yet.

Given the time and resource limits the EG has, I propose to simply add a note to the spec saying that "when running on a Java EE Application Server/when CDI is available, resources and providers MUST be available for CDI extensions to process it, just like if had a CDI bean defining annotation", e.g.: providers and resources are discovered by the CDI runtime like any other bean, but *they don't need to be treated as beans*. That basically ressembled the behaviour offered by trimmed archives on CDI 2.0 [2].

What we gain with that? Users could easily create an extension to make all the resources @RequestScoped, while maintaining the spec clean (further integration would need more discussion). At the moment it's not possible to do that with CDI [3] and you have to mark all your classes as @Dependent (a practice that is not so uncommon [4]) or mark CDI bean discovery "all"/"trimmed".

How do you see it? Do you think it's viable at this time?




--






Re: CDI integration

Sergey Beryozkin
 

Hi

Lest not dramatize it,
difficult, confusing, all because of @Context ? I'm not going to comment.

As well as re this 'ownership' claim of JAX-RS by EE.

Sergey

On 31/05/17 11:44, Arjan Tijms wrote:
Hi,

On Wed, May 31, 2017 at 11:52 AM, Sergey Beryozkin <sberyozkin@...> wrote:
@Context is that little thing that has helped to make JAX-RS visible outside of the EE world, as opposed to it be yet another EE spec.

It's not just another EE spec, but one of the fundamental EE specs.

 
Rather than trying to keep JAX-RS more and more dependent on EE pieces I'd like to encourage us keeping it as open as possible

IMHO; open as possible also means that you eventually commit to nothing and only make it more difficult and confusing to use in its primary environment. 

Kind regards.
Arjan Tijms



 
Sergey


On 31/05/17 10:44, Sebastian Daschner wrote:

Yes, agreed.

Especially the ability to @Inject JAX-RS managed objects (basically what is @Context today) would be very helpful. That enables to inject UriInfo within the EE application and also getting rid of @Context to streamline Java EE further :-)

Cheers,
Sebastian
   


On 05/31/2017 03:12 PM, Christian Kaltepoth wrote:
I agree with Guillermo and Arjan that further CDI alignment is very important for JAX-RS. 

It would be great to see some EG discussion about this.

Christian

2017-05-25 20:13 GMT+02:00 Arjan Tijms <arjan.tijms@...>:
Hi,

I too would greatly love to see this happening. CDI alignment IMHO should have been -the- major theme of Java EE and unfortunately too few steps have been made towards that goal.

Kind regards,
Arjan Tijms



On Thu, May 25, 2017 at 8:04 PM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,

Time is quickly running out, and I guess what the plans are regarding CDI alignment. There's an open issue [1] labeled as "2.1-candidate" but it seems no work has been done on that yet.

Given the time and resource limits the EG has, I propose to simply add a note to the spec saying that "when running on a Java EE Application Server/when CDI is available, resources and providers MUST be available for CDI extensions to process it, just like if had a CDI bean defining annotation", e.g.: providers and resources are discovered by the CDI runtime like any other bean, but *they don't need to be treated as beans*. That basically ressembled the behaviour offered by trimmed archives on CDI 2.0 [2].

What we gain with that? Users could easily create an extension to make all the resources @RequestScoped, while maintaining the spec clean (further integration would need more discussion). At the moment it's not possible to do that with CDI [3] and you have to mark all your classes as @Dependent (a practice that is not so uncommon [4]) or mark CDI bean discovery "all"/"trimmed".

How do you see it? Do you think it's viable at this time?




--





Re: CDI integration

Arjan Tijms
 

Hi,

On Wed, May 31, 2017 at 11:52 AM, Sergey Beryozkin <sberyozkin@...> wrote:
@Context is that little thing that has helped to make JAX-RS visible outside of the EE world, as opposed to it be yet another EE spec.

It's not just another EE spec, but one of the fundamental EE specs.

 
Rather than trying to keep JAX-RS more and more dependent on EE pieces I'd like to encourage us keeping it as open as possible

IMHO; open as possible also means that you eventually commit to nothing and only make it more difficult and confusing to use in its primary environment. 

Kind regards.
Arjan Tijms



 
Sergey


On 31/05/17 10:44, Sebastian Daschner wrote:

Yes, agreed.

Especially the ability to @Inject JAX-RS managed objects (basically what is @Context today) would be very helpful. That enables to inject UriInfo within the EE application and also getting rid of @Context to streamline Java EE further :-)

Cheers,
Sebastian
   


On 05/31/2017 03:12 PM, Christian Kaltepoth wrote:
I agree with Guillermo and Arjan that further CDI alignment is very important for JAX-RS. 

It would be great to see some EG discussion about this.

Christian

2017-05-25 20:13 GMT+02:00 Arjan Tijms <arjan.tijms@...>:
Hi,

I too would greatly love to see this happening. CDI alignment IMHO should have been -the- major theme of Java EE and unfortunately too few steps have been made towards that goal.

Kind regards,
Arjan Tijms



On Thu, May 25, 2017 at 8:04 PM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,

Time is quickly running out, and I guess what the plans are regarding CDI alignment. There's an open issue [1] labeled as "2.1-candidate" but it seems no work has been done on that yet.

Given the time and resource limits the EG has, I propose to simply add a note to the spec saying that "when running on a Java EE Application Server/when CDI is available, resources and providers MUST be available for CDI extensions to process it, just like if had a CDI bean defining annotation", e.g.: providers and resources are discovered by the CDI runtime like any other bean, but *they don't need to be treated as beans*. That basically ressembled the behaviour offered by trimmed archives on CDI 2.0 [2].

What we gain with that? Users could easily create an extension to make all the resources @RequestScoped, while maintaining the spec clean (further integration would need more discussion). At the moment it's not possible to do that with CDI [3] and you have to mark all your classes as @Dependent (a practice that is not so uncommon [4]) or mark CDI bean discovery "all"/"trimmed".

How do you see it? Do you think it's viable at this time?




--




Re: CDI integration

Sergey Beryozkin
 

@Context is that little thing that has helped to make JAX-RS visible outside of the EE world, as opposed to it be yet another EE spec.
Rather than trying to keep JAX-RS more and more dependent on EE pieces I'd like to encourage us keeping it as open as possible

Sergey

On 31/05/17 10:44, Sebastian Daschner wrote:

Yes, agreed.

Especially the ability to @Inject JAX-RS managed objects (basically what is @Context today) would be very helpful. That enables to inject UriInfo within the EE application and also getting rid of @Context to streamline Java EE further :-)

Cheers,
Sebastian
   


On 05/31/2017 03:12 PM, Christian Kaltepoth wrote:
I agree with Guillermo and Arjan that further CDI alignment is very important for JAX-RS. 

It would be great to see some EG discussion about this.

Christian

2017-05-25 20:13 GMT+02:00 Arjan Tijms <arjan.tijms@...>:
Hi,

I too would greatly love to see this happening. CDI alignment IMHO should have been -the- major theme of Java EE and unfortunately too few steps have been made towards that goal.

Kind regards,
Arjan Tijms



On Thu, May 25, 2017 at 8:04 PM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,

Time is quickly running out, and I guess what the plans are regarding CDI alignment. There's an open issue [1] labeled as "2.1-candidate" but it seems no work has been done on that yet.

Given the time and resource limits the EG has, I propose to simply add a note to the spec saying that "when running on a Java EE Application Server/when CDI is available, resources and providers MUST be available for CDI extensions to process it, just like if had a CDI bean defining annotation", e.g.: providers and resources are discovered by the CDI runtime like any other bean, but *they don't need to be treated as beans*. That basically ressembled the behaviour offered by trimmed archives on CDI 2.0 [2].

What we gain with that? Users could easily create an extension to make all the resources @RequestScoped, while maintaining the spec clean (further integration would need more discussion). At the moment it's not possible to do that with CDI [3] and you have to mark all your classes as @Dependent (a practice that is not so uncommon [4]) or mark CDI bean discovery "all"/"trimmed".

How do you see it? Do you think it's viable at this time?




--



Re: CDI integration

Sebastian Daschner
 

Yes, agreed.

Especially the ability to @Inject JAX-RS managed objects (basically what is @Context today) would be very helpful. That enables to inject UriInfo within the EE application and also getting rid of @Context to streamline Java EE further :-)

Cheers,
Sebastian
   


On 05/31/2017 03:12 PM, Christian Kaltepoth wrote:
I agree with Guillermo and Arjan that further CDI alignment is very important for JAX-RS. 

It would be great to see some EG discussion about this.

Christian

2017-05-25 20:13 GMT+02:00 Arjan Tijms <arjan.tijms@...>:
Hi,

I too would greatly love to see this happening. CDI alignment IMHO should have been -the- major theme of Java EE and unfortunately too few steps have been made towards that goal.

Kind regards,
Arjan Tijms



On Thu, May 25, 2017 at 8:04 PM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,

Time is quickly running out, and I guess what the plans are regarding CDI alignment. There's an open issue [1] labeled as "2.1-candidate" but it seems no work has been done on that yet.

Given the time and resource limits the EG has, I propose to simply add a note to the spec saying that "when running on a Java EE Application Server/when CDI is available, resources and providers MUST be available for CDI extensions to process it, just like if had a CDI bean defining annotation", e.g.: providers and resources are discovered by the CDI runtime like any other bean, but *they don't need to be treated as beans*. That basically ressembled the behaviour offered by trimmed archives on CDI 2.0 [2].

What we gain with that? Users could easily create an extension to make all the resources @RequestScoped, while maintaining the spec clean (further integration would need more discussion). At the moment it's not possible to do that with CDI [3] and you have to mark all your classes as @Dependent (a practice that is not so uncommon [4]) or mark CDI bean discovery "all"/"trimmed".

How do you see it? Do you think it's viable at this time?




--


Re: CDI integration

 

I agree with Guillermo and Arjan that further CDI alignment is very important for JAX-RS. 

It would be great to see some EG discussion about this.

Christian

2017-05-25 20:13 GMT+02:00 Arjan Tijms <arjan.tijms@...>:

Hi,

I too would greatly love to see this happening. CDI alignment IMHO should have been -the- major theme of Java EE and unfortunately too few steps have been made towards that goal.

Kind regards,
Arjan Tijms



On Thu, May 25, 2017 at 8:04 PM, Guillermo González de Agüero <z06.guillermo@...> wrote:
Hi,

Time is quickly running out, and I guess what the plans are regarding CDI alignment. There's an open issue [1] labeled as "2.1-candidate" but it seems no work has been done on that yet.

Given the time and resource limits the EG has, I propose to simply add a note to the spec saying that "when running on a Java EE Application Server/when CDI is available, resources and providers MUST be available for CDI extensions to process it, just like if had a CDI bean defining annotation", e.g.: providers and resources are discovered by the CDI runtime like any other bean, but *they don't need to be treated as beans*. That basically ressembled the behaviour offered by trimmed archives on CDI 2.0 [2].

What we gain with that? Users could easily create an extension to make all the resources @RequestScoped, while maintaining the spec clean (further integration would need more discussion). At the moment it's not possible to do that with CDI [3] and you have to mark all your classes as @Dependent (a practice that is not so uncommon [4]) or mark CDI bean discovery "all"/"trimmed".

How do you see it? Do you think it's viable at this time?






Re: PATCH support on the client

Andy McCright
 

That is more-or-less my opinion too.  I'd prefer that we supported the patch() method fully (not optionally), but if the decision is support it optionally or not at all, I'd choose not at all.
 
On this topic, is it possible to remove the HttpUrlConnection restriction in Java 9 so that we could have more flexibility for future JAX-RS Client APIs?
 
Thanks,
 
Andy


J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 

----- Original message -----
From: "Alessio Soldano" <asoldano@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] PATCH support on the client
Date: Tue, May 30, 2017 6:42 AM
 
Il 30/05/2017 10:48, Sergey Beryozkin ha scritto:
> Re patch() - I've no strong opinion whether this actual method stays
> or not, because we still have method(), and that was my point when I
> replied to Markus,
> we can/should not enforce an 'either works for all the platform or not
> at all' solution. Having patch() staying won't change anything except
> for having this optional method be more visible which is what I guess
> adding this method was mainly about. If dropping it will make API less
> controversial then it is fine...
Same feeling here.

Cheers
Alessio

>
> Thanks, Sergey
>
> On 30/05/17 09:13, Pavel Bucek wrote:
>> The issue with Sync/Async/RxInvoker#patch methods is similar to what
>> we do have with Sync/Async/RxInvoker#method, but surprisingly #method
>> doesn't mention anything about unsupported HTTP methods or runtime
>> requirements. On the other hand, there seem to be general agreement
>> about the existence of unsupported HTTP methods.
>>
>> The problem with #patch is that it is extracted (similarly as #get,
>> #post, ..), so anyone would assume that it has to work.
>>
>> If there is a strong opposition to marking those methods as optional,
>> we can remove them completely, as suggested. #method is always there,
>> so the functionality is not gone and it might make more sense from
>> certain point of view.
>>
>> Seems like Markus already stated, that he strongly prefers to remove
>> #patch (compared to keeping them as optional), Sergey might be ok
>> with #patch staying int the client API (feel free to correct me). Any
>> other opinions?
>>
>> (note that removing methods from the API is simple; we certainly can
>> choose to re-add them later. We also could only lift the
>> "optionality" and creating less disturbing change in the future).
>>
>> Thanks,
>> Pavel
>>
>>
>>
>> On 29/05/2017 18:28, Sergey Beryozkin wrote:
>>> The issue applies not only to PATCH but to all other methods which
>>> happen not be known to HttpUrlConnection.
>>> But rather than say something along the lines "only well-known
>>> verbs" can be supported and be forever restricted by this strange
>>> HttpUrlConnection restriction given that all stacks can work with
>>> HttpClient, I'd rather have JAX-RS 2.1 be much more open.
>>>
>>> Even Collection API in java.util. has a number of optional methods.  
>>> Some ISVs might decide not to use this optional method and use their
>>> own code - but that won't make their code any more portable as it
>>> will be tied to HttpClient or similar....
>>>
>>>
>>> Sergey
>>> On 29/05/17 17:19, Markus KARG wrote:
>>>> My opinion is that either we support it completely or not at all.
>>>> Making it optional renders the feature useless for ISVs: If I
>>>> cannot rely on it being there on _all_ platforms, I will _never_
>>>> use it, or I will _always_ bring it with me on my own. So it would
>>>> be good for nothing.
>>>> -Markus
>>>>
>>>> -----Original Message-----
>>>> From: jaxrs-spec@javaee.groups.io
>>>> [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
>>>> Sent: Montag, 29. Mai 2017 17:23
>>>> To: jaxrs-spec@javaee.groups.io
>>>> Subject: [jaxrs] PATCH support on the client
>>>>
>>>> Dear experts,
>>>>
>>>> we'd like to make the HTTP PATCH support on the client optional,
>>>> throwing UnsupportedOperationException on client runtimes, which
>>>> don't support that method.
>>>>
>>>> I know that we already had a discussion about this, but we
>>>> concluded that requiring something without having support from the
>>>> target JDK might be too cumbersome for some environments.
>>>>
>>>> This wouldn't change anything on the server side, it's purely about
>>>> the client (reflecting the issues related to HttpUrlConnection and
>>>> derived implementations).
>>>>
>>>> Any comments/suggestions welcomed.
>>>>
>>>> Thanks,
>>>> Pavel
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>



 
 


Re: PATCH support on the client

Alessio Soldano
 

Il 30/05/2017 10:48, Sergey Beryozkin ha scritto:
Re patch() - I've no strong opinion whether this actual method stays or not, because we still have method(), and that was my point when I replied to Markus,
we can/should not enforce an 'either works for all the platform or not at all' solution. Having patch() staying won't change anything except for having this optional method be more visible which is what I guess adding this method was mainly about. If dropping it will make API less controversial then it is fine...
Same feeling here.

Cheers
Alessio


Thanks, Sergey

On 30/05/17 09:13, Pavel Bucek wrote:
The issue with Sync/Async/RxInvoker#patch methods is similar to what we do have with Sync/Async/RxInvoker#method, but surprisingly #method doesn't mention anything about unsupported HTTP methods or runtime requirements. On the other hand, there seem to be general agreement about the existence of unsupported HTTP methods.

The problem with #patch is that it is extracted (similarly as #get, #post, ..), so anyone would assume that it has to work.

If there is a strong opposition to marking those methods as optional, we can remove them completely, as suggested. #method is always there, so the functionality is not gone and it might make more sense from certain point of view.

Seems like Markus already stated, that he strongly prefers to remove #patch (compared to keeping them as optional), Sergey might be ok with #patch staying int the client API (feel free to correct me). Any other opinions?

(note that removing methods from the API is simple; we certainly can choose to re-add them later. We also could only lift the "optionality" and creating less disturbing change in the future).

Thanks,
Pavel



On 29/05/2017 18:28, Sergey Beryozkin wrote:
The issue applies not only to PATCH but to all other methods which happen not be known to HttpUrlConnection.
But rather than say something along the lines "only well-known verbs" can be supported and be forever restricted by this strange HttpUrlConnection restriction given that all stacks can work with HttpClient, I'd rather have JAX-RS 2.1 be much more open.

Even Collection API in java.util. has a number of optional methods. Some ISVs might decide not to use this optional method and use their own code - but that won't make their code any more portable as it will be tied to HttpClient or similar....


Sergey
On 29/05/17 17:19, Markus KARG wrote:
My opinion is that either we support it completely or not at all. Making it optional renders the feature useless for ISVs: If I cannot rely on it being there on _all_ platforms, I will _never_ use it, or I will _always_ bring it with me on my own. So it would be good for nothing.
-Markus

-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Montag, 29. Mai 2017 17:23
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] PATCH support on the client

Dear experts,

we'd like to make the HTTP PATCH support on the client optional, throwing UnsupportedOperationException on client runtimes, which don't support that method.

I know that we already had a discussion about this, but we concluded that requiring something without having support from the target JDK might be too cumbersome for some environments.

This wouldn't change anything on the server side, it's purely about the client (reflecting the issues related to HttpUrlConnection and derived implementations).

Any comments/suggestions welcomed.

Thanks,
Pavel













Re: PATCH support on the client

Sergey Beryozkin
 

Hi Pavel

Right, that what I was also implying, that API already allows to use any HTTP method names, so it is not only about PATCH.
So we should have method(String) variations docs updated.

Re patch() - I've no strong opinion whether this actual method stays or not, because we still have method(), and that was my point when I replied to Markus,
we can/should not enforce an 'either works for all the platform or not at all' solution. Having patch() staying won't change anything except for having this optional method be more visible which is what I guess adding this method was mainly about. If dropping it will make API less controversial then it is fine...

Thanks, Sergey

On 30/05/17 09:13, Pavel Bucek wrote:
The issue with Sync/Async/RxInvoker#patch methods is similar to what we do have with Sync/Async/RxInvoker#method, but surprisingly #method doesn't mention anything about unsupported HTTP methods or runtime requirements. On the other hand, there seem to be general agreement about the existence of unsupported HTTP methods.

The problem with #patch is that it is extracted (similarly as #get, #post, ..), so anyone would assume that it has to work.

If there is a strong opposition to marking those methods as optional, we can remove them completely, as suggested. #method is always there, so the functionality is not gone and it might make more sense from certain point of view.

Seems like Markus already stated, that he strongly prefers to remove #patch (compared to keeping them as optional), Sergey might be ok with #patch staying int the client API (feel free to correct me). Any other opinions?

(note that removing methods from the API is simple; we certainly can choose to re-add them later. We also could only lift the "optionality" and creating less disturbing change in the future).

Thanks,
Pavel



On 29/05/2017 18:28, Sergey Beryozkin wrote:
The issue applies not only to PATCH but to all other methods which happen not be known to HttpUrlConnection.
But rather than say something along the lines "only well-known verbs" can be supported and be forever restricted by this strange HttpUrlConnection restriction given that all stacks can work with HttpClient, I'd rather have JAX-RS 2.1 be much more open.

Even Collection API in java.util. has a number of optional methods. Some ISVs might decide not to use this optional method and use their own code - but that won't make their code any more portable as it will be tied to HttpClient or similar....


Sergey
On 29/05/17 17:19, Markus KARG wrote:
My opinion is that either we support it completely or not at all. Making it optional renders the feature useless for ISVs: If I cannot rely on it being there on _all_ platforms, I will _never_ use it, or I will _always_ bring it with me on my own. So it would be good for nothing.
-Markus

-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Montag, 29. Mai 2017 17:23
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] PATCH support on the client

Dear experts,

we'd like to make the HTTP PATCH support on the client optional, throwing UnsupportedOperationException on client runtimes, which don't support that method.

I know that we already had a discussion about this, but we concluded that requiring something without having support from the target JDK might be too cumbersome for some environments.

This wouldn't change anything on the server side, it's purely about the client (reflecting the issues related to HttpUrlConnection and derived implementations).

Any comments/suggestions welcomed.

Thanks,
Pavel











Re: PATCH support on the client

Pavel Bucek
 

The issue with Sync/Async/RxInvoker#patch methods is similar to what we do have with Sync/Async/RxInvoker#method, but surprisingly #method doesn't mention anything about unsupported HTTP methods or runtime requirements. On the other hand, there seem to be general agreement about the existence of unsupported HTTP methods.

The problem with #patch is that it is extracted (similarly as #get, #post, ..), so anyone would assume that it has to work.

If there is a strong opposition to marking those methods as optional, we can remove them completely, as suggested. #method is always there, so the functionality is not gone and it might make more sense from certain point of view.

Seems like Markus already stated, that he strongly prefers to remove #patch (compared to keeping them as optional), Sergey might be ok with #patch staying int the client API (feel free to correct me). Any other opinions?

(note that removing methods from the API is simple; we certainly can choose to re-add them later. We also could only lift the "optionality" and creating less disturbing change in the future).

Thanks,
Pavel

On 29/05/2017 18:28, Sergey Beryozkin wrote:
The issue applies not only to PATCH but to all other methods which happen not be known to HttpUrlConnection.
But rather than say something along the lines "only well-known verbs" can be supported and be forever restricted by this strange HttpUrlConnection restriction given that all stacks can work with HttpClient, I'd rather have JAX-RS 2.1 be much more open.

Even Collection API in java.util. has a number of optional methods. Some ISVs might decide not to use this optional method and use their own code - but that won't make their code any more portable as it will be tied to HttpClient or similar....


Sergey
On 29/05/17 17:19, Markus KARG wrote:
My opinion is that either we support it completely or not at all. Making it optional renders the feature useless for ISVs: If I cannot rely on it being there on _all_ platforms, I will _never_ use it, or I will _always_ bring it with me on my own. So it would be good for nothing.
-Markus

-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Montag, 29. Mai 2017 17:23
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] PATCH support on the client

Dear experts,

we'd like to make the HTTP PATCH support on the client optional, throwing UnsupportedOperationException on client runtimes, which don't support that method.

I know that we already had a discussion about this, but we concluded that requiring something without having support from the target JDK might be too cumbersome for some environments.

This wouldn't change anything on the server side, it's purely about the client (reflecting the issues related to HttpUrlConnection and derived implementations).

Any comments/suggestions welcomed.

Thanks,
Pavel









Re: PATCH support on the client

 

In fact no ISV is using that optional methods unless they package their app with a particular JRE.
-Markus

-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Sergey Beryozkin
Sent: Montag, 29. Mai 2017 18:29
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] PATCH support on the client

The issue applies not only to PATCH but to all other methods which happen not be known to HttpUrlConnection.
But rather than say something along the lines "only well-known verbs"
can be supported and be forever restricted by this strange HttpUrlConnection restriction given that all stacks can work with HttpClient, I'd rather have JAX-RS 2.1 be much more open.

Even Collection API in java.util. has a number of optional methods.
Some ISVs might decide not to use this optional method and use their own code - but that won't make their code any more portable as it will be tied to HttpClient or similar....


Sergey
On 29/05/17 17:19, Markus KARG wrote:
My opinion is that either we support it completely or not at all. Making it optional renders the feature useless for ISVs: If I cannot rely on it being there on _all_ platforms, I will _never_ use it, or I will _always_ bring it with me on my own. So it would be good for nothing.
-Markus

-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io]
On Behalf Of Pavel Bucek
Sent: Montag, 29. Mai 2017 17:23
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] PATCH support on the client

Dear experts,

we'd like to make the HTTP PATCH support on the client optional, throwing UnsupportedOperationException on client runtimes, which don't support that method.

I know that we already had a discussion about this, but we concluded that requiring something without having support from the target JDK might be too cumbersome for some environments.

This wouldn't change anything on the server side, it's purely about the client (reflecting the issues related to HttpUrlConnection and derived implementations).

Any comments/suggestions welcomed.

Thanks,
Pavel








Re: PATCH support on the client

Sergey Beryozkin
 

The issue applies not only to PATCH but to all other methods which happen not be known to HttpUrlConnection.
But rather than say something along the lines "only well-known verbs" can be supported and be forever restricted by this strange HttpUrlConnection restriction given that all stacks can work with HttpClient, I'd rather have JAX-RS 2.1 be much more open.

Even Collection API in java.util. has a number of optional methods. Some ISVs might decide not to use this optional method and use their own code - but that won't make their code any more portable as it will be tied to HttpClient or similar....


Sergey

On 29/05/17 17:19, Markus KARG wrote:
My opinion is that either we support it completely or not at all. Making it optional renders the feature useless for ISVs: If I cannot rely on it being there on _all_ platforms, I will _never_ use it, or I will _always_ bring it with me on my own. So it would be good for nothing.
-Markus

-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Montag, 29. Mai 2017 17:23
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] PATCH support on the client

Dear experts,

we'd like to make the HTTP PATCH support on the client optional, throwing UnsupportedOperationException on client runtimes, which don't support that method.

I know that we already had a discussion about this, but we concluded that requiring something without having support from the target JDK might be too cumbersome for some environments.

This wouldn't change anything on the server side, it's purely about the client (reflecting the issues related to HttpUrlConnection and derived implementations).

Any comments/suggestions welcomed.

Thanks,
Pavel







Re: PATCH support on the client

 

My opinion is that either we support it completely or not at all. Making it optional renders the feature useless for ISVs: If I cannot rely on it being there on _all_ platforms, I will _never_ use it, or I will _always_ bring it with me on my own. So it would be good for nothing.
-Markus

-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Montag, 29. Mai 2017 17:23
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] PATCH support on the client

Dear experts,

we'd like to make the HTTP PATCH support on the client optional, throwing UnsupportedOperationException on client runtimes, which don't support that method.

I know that we already had a discussion about this, but we concluded that requiring something without having support from the target JDK might be too cumbersome for some environments.

This wouldn't change anything on the server side, it's purely about the client (reflecting the issues related to HttpUrlConnection and derived implementations).

Any comments/suggestions welcomed.

Thanks,
Pavel


PATCH support on the client

Pavel Bucek
 

Dear experts,

we'd like to make the HTTP PATCH support on the client optional, throwing UnsupportedOperationException on client runtimes, which don't support that method.

I know that we already had a discussion about this, but we concluded that requiring something without having support from the target JDK might be too cumbersome for some environments.

This wouldn't change anything on the server side, it's purely about the client (reflecting the issues related to HttpUrlConnection and derived implementations).

Any comments/suggestions welcomed.

Thanks,
Pavel


Re: #544: Localization & BeanValidation

 

Hi Gunnar,

sorry, the term "priority" was a bit misleading in this context. Actually it uses the "quality value" from the "Accept-Language" header. 


Christian

2017-05-29 14:26 GMT+02:00 Gunnar Morling via Groups.Io <gunnar.morling@...>:

Hi Christian,

> The default implementation basically resolves the locale by parsing the
> Accept-Locale request header and resolving the locale with the highest
> priority.

This seems very useful, pretty much like what could be useful within
JAX-RS itself. That selected Locale could then be used with a
specifically set up message interpolator, just as JSF defines this
integration with Bean Validation.

Out of curiosity, how is that priority be defined?

--Gunnar



2017-05-28 16:00 GMT+02:00 Christian Kaltepoth <christian@...>:
> Hey Pavel,
>
>> The struggle here is with the SupportedLanguagesProvider - it feels like
>> it should be used for something more than BV - I think it's fair to say that
>> if localizaiton of BV error messages is the sole purpose of such provider,
>> it shouldn't be introduced. And I can't think of any other sensible use
>> right now.
>
>
> I would like to take the opportunity to describe what MVC did to support
> internationalization which relates to the issue we are discussing here. As
> MVC builds on top of JAX-RS, this may (or may not) be interesting for you.
>
> For MVC we identified a few locale-dependent aspects which we had to
> support:
>
> Data type conversion as part of the data binding mechanism needs to be
> locale aware. So something like @FormParam("price") BigDecimal price needs
> to be parsed according to the number formatting rules of the specific
> locale.
> Formatting data according to locale dependent rules when rending the view
> (date format / number format). This certainly isn't something relevant for
> JAX-RS.
> Generating binding and validation errors message in the specific language.
> This is basically what we are talking about here.
>
> To support these scenarios we defined the term "request locale" as the
> locale which is used for any locale-dependent operation within the lifecycle
> of a request. The request locale is resolved for each request using the
> following SPI:
>
>   public interface LocaleResolver {
>     Locale resolveLocale(LocaleResolverContext context);
>   }
>
> The default implementation basically resolves the locale by parsing the
> Accept-Locale request header and resolving the locale with the highest
> priority.
>
> But developers can customize this by providing their own resolver. So if the
> developer wants to support only a specific subset of locales, he could
> simply create a custom resolver and match the supported locales against the
> Accept-Locale header as described in Pavel's previous mail.
>
> You can see the full SPI here:
>
> https://github.com/mvc-spec/mvc-spec/tree/master/api/src/main/java/javax/mvc/locale
>
> All the details are described in the MVC spec document (pages 37-38):
>
> https://github.com/mvc-spec/mvc-spec/raw/master/spec/spec.pdf
>
> I'm not sure if anything described here could be useful for JAX-RS. Of cause
> we (the MVC EG) would be happy to see any of our APIs to be integrated into
> JAX-RS.
>
> Christian
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>
>