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?

Regards,

Guillermo González de Agüero

[1] https://github.com/jax-rs/api/issues/60
[2] http://weld.cdi-spec.org/news/#_trimmed_bean_archives
[3] https://issues.jboss.org/browse/CDI-701
[4] https://blog-rmannibucau.rhcloud.com/#/post/jaxrs-response-filter

--

Christian Kaltepoth

Blog: http://blog.kaltepoth.de/

Twitter: http://twitter.com/chkal

GitHub: https://github.com/chkal