1. jaxrs-spec@javaee.groups.io

Re: CDI integration

Guillermo González de Agüero
 

Hi Pavel,

First, thanks for taking the time to consider this.

On Fri, Jun 2, 2017 at 3:33 PM, Pavel Bucek <pavel.bucek@...> wrote:

Hi Guillermo,

this is problematic at least. If there is no API in the CDI spec for requested feature, it would mean that the spec depends on an implementation feature of CDI container (I believe it is Weld in this case). What if someone would like to run against different CDI implementation?

That would force JAX-RS implementations to create container specific code for each container which it wants to integrate with. I do see that it might not be a problem for some implementations, especially when there is some impl which is designated to live only in single specific container, but generally it could potentially limit some JAX-RS implementers.

Arjan has summarized the idea. With this option, JAX-RS implementations themselves will stay the same as today. Taking Jersey as an example, if I'm an application server vendor, it will be my job to find a CDI implemenetation that allows me to make @Path behave like a "bean defining annotation". But Jersey won't have nothing to do with it.

Ad @Stereotype - I'd need to check whether we can easily do that, since it would create a dependency on javax.enterprise.inject. I don't understand the remark about that annotation not being there in the runtime - it will be there, it has retention runtime (otherwise it wouldn't work)

I meant CDI will only be needed at (JAX-RS implementation) compile time. Applications won't need it as annotations not present on the classpath are just erased at runtime. So people using Spring or wathever non-CDI framework won't see any difference. Hope it clearer now?

Maybe you meant that it won't be necessary to add it to JAX-RS Resource, which already has @Path annotation. Also, @RequestScoped would need to be added as well, since JAX-RS resources are request scoped by default.

So what if we have

@Stereotype
@RequestScoped
public @interface Path { ... }

and @Path is used as an annotation on a class - is it possible to somehow override the scope to something else?

Of course. Annotations directly present on the class take precedence here [1], so noone will see any side effect if they had already defined a different scope.

Also, would it be an issue if @Path is used on a resource method? (which is a valid usecase)

This would not affect it either. CDI only uses stereotypes on beans, so if that method is not annotated also with javax.enterprise.Produces, CDI will not use it. And again, that default scope could be overrided.

Thanks,
Pavel


On 01/06/2017 20:20, Guillermo González de Agüero wrote:
Hi Pavel,

It's not currently doable right now with the standard APIs. My original proposal was to require the application server to do it in a vendor specific manner. WildFly already does it that way [1]. The work there would most probably fall on CDI integration implementations. That was to prevent changes to the JAX-RS api.

But there's also a standard way that would work, and that's marking annotating @Path with @Stereotype. Doing that will make CDI discover resources, without any more side effect I'm aware of. Should a future version decide resources should be request scoped, adding the @RequestScoped annotation to it will do the work.

JSF already did something pretty similar with Converters, but with the @Qualifier annotation [2].

Given how annotations work on Java, it wouldn't be a problem for non CDI users not having those annotations on the classpath; they will just not exist at runtime.

Do you think that's feasible?


Regards,

Guillermo González de Agüero.

[1] https://github.com/wildfly/wildfly/blob/master/jaxrs/src/main/java/org/jboss/as/jaxrs/deployment/JaxrsAnnotationProcessor.java#L48
[2] https://github.com/javaserverfaces/mojarra/blob/2fe586e0b9b23a11b9168b30610b2afadeecdb41/impl/src/main/java/javax/faces/convert/FacesConverter.java#L100

Guillermo González de Agüero

On Thu, Jun 1, 2017 at 10:56 AM, Pavel Bucek <pavel.bucek@...> wrote:

Hello Guillermo,

ad "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"

How that can be done? (yes, I'm looking for code example).

Thanks,
Pavel


On 25/05/2017 20:04, Guillermo González de Agüero 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] http://docs.jboss.org/weld/reference/3.0.0.CR1/en-US/html/stereotypes.html#_default_scope_for_a_stereotype
Join jaxrs-spec@javaee.groups.io to automatically receive all group messages.
More
Home Messages Hashtags About Features Pricing Updates Terms Help Twitter