|
Re: CDI integration
Sorry for the typo, I meant to say that "ignoring of the fact that major non-EE containers are *now* thought by"
Sorry for the typo, I meant to say that "ignoring of the fact that major non-EE containers are *now* thought by"
|
By
Sergey Beryozkin
·
#103
·
|
|
Re: CDI integration
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
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
|
By
Sergey Beryozkin
·
#102
·
|
|
Re: CDI integration
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
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
|
By
Sergey Beryozkin
·
#101
·
|
|
Re: CDI integration
Why?
By
Arjan Tijms
·
#100
·
|
|
Re: CDI integration
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
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
|
By
Arjan Tijms
·
#99
·
|
|
Re: CDI integration
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
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
|
By
Sergey Beryozkin
·
#98
·
|
|
Re: CDI integration
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.
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.
|
By
Sergey Beryozkin
·
#97
·
|
|
Re: CDI integration
Hi,
It's not just another EE spec, but one of the fundamental EE specs.
IMHO; open as possible also means that you eventually commit to nothing and only make it more difficult and confusing to use
Hi,
It's not just another EE spec, but one of the fundamental EE specs.
IMHO; open as possible also means that you eventually commit to nothing and only make it more difficult and confusing to use
|
By
Arjan Tijms
·
#96
·
|
|
Re: CDI integration
@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
@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
|
By
Sergey Beryozkin
·
#95
·
|
|
Re: CDI integration
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
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
|
By
Sebastian Daschner
·
#94
·
|
|
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
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
|
By
Christian Kaltepoth
·
#93
·
|
|
Re: PATCH support on the client
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
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
|
By
Andy McCright
·
#92
·
|
|
Re: PATCH support on the client
Same feeling here.
Cheers
Alessio
Same feeling here.
Cheers
Alessio
|
By
Alessio Soldano
·
#91
·
|
|
Re: PATCH support on the client
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
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
|
By
Sergey Beryozkin
·
#90
·
|
|
Re: PATCH support on the client
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
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
|
By
Pavel Bucek
·
#89
·
|
|
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
In fact no ISV is using that optional methods unless they package their app with a particular JRE.
-Markus
|
By
Markus KARG
·
#88
·
|
|
Re: 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
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
|
By
Sergey Beryozkin
·
#87
·
|
|
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,
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,
|
By
Markus KARG
·
#86
·
|
|
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
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
|
By
Pavel Bucek
·
#85
·
|
|
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.
See:
Hi Gunnar,
sorry, the term "priority" was a bit misleading in this context. Actually it uses the "quality value" from the "Accept-Language" header.
See:
|
By
Christian Kaltepoth
·
#84
·
|