JAX-RS and CDI

[Arjan Tijms]

Hi,

Recently I had a brief chat with Alasdair about the fact that JAX-RS is in fact not natively CDI. This means JAX-RS resources have their own component model and effectively interpret some of the well known annotations like @Inject on their own. Things like Interceptors don't automatically work on JAX-RS resources.

With the micro profile being a new profile, I wonder if it might make sense to investigate how feasible it will be to start out with a JAX-RS variant that's fully CDI based. MVC did something like this as well. MVC controllers are JAX-RS based but have to be CDI managed beans:

2.1.1

"Unlike in JAX-RS where resource classes can be native (created and managed by JAX-RS), CDI beans, managed beans or EJBs, MVC classes are REQUIRED to be CDI-managed beans only [mvc:cdi-beans]. It follows that a hybrid class that contains a mix of JAX-RS resource methods and MVC controllers must also be CDI managed."

This topic has been discussed in the JAX-RS EG a while ago, but since that EG doesn't seem so active anymore no steps have been taken afaik towards this goal.

Thoughts?

Kind regards,

Arjan Tijms

[Antonio Goncalves]

I suppose this brings another discussion : which of the 3 proposed JSRs (JAX-RS, CDI, JSon-P) are not active anymore ? If we want to move the Micro Profile based on these JSRs, they might have to evolved. If they don't, are they good candidates for the Micro Profile ? Starting out a variant of JAX-RS would be a difficult and dangerous move (fractionning the REST specifications and communities). JAX-RS is very important nowadays.

Antonio

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b0702b38-d499-4b2c-8487-e44b53203ad2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France

[Arjan Tijms]

On Wednesday, July 13, 2016 at 6:52:54 PM UTC+2, Antonio Goncalves wrote:

I suppose this brings another discussion : which of the 3 proposed JSRs (JAX-RS, CDI, JSon-P) are not active anymore ? If we want to move the Micro Profile based on these JSRs, they might have to evolved. If they don't, are they good candidates for the Micro Profile ?

Indeed, that's something I wanted to ask separately as well. What are the plans (if any) to evolve any of those base JSRs and thus specifically JAX-RS? Contrary to MVC, Security API and JSF, I don't think anyone outside Oracle has committer access to the JAX-RS RI, have they?

What if JAX-RS will not become active anymore for a long time?

 

Starting out a variant of JAX-RS would be a difficult and dangerous move (fractionning the REST specifications and communities). JAX-RS is very important nowadays.

You're right that fractioning would not be a good idea, but would adding a constraint like: "in the micro profile JAX-RS resources are only allowed to be CDI managed beans" be really fractioning?

Kind regards,

Arjan Tijms

[Will Hartung]

On Wednesday, July 13, 2016 at 9:27:00 AM UTC-7, Arjan Tijms wrote:

Hi,

Recently I had a brief chat with Alasdair about the fact that JAX-RS is in fact not natively CDI. This means JAX-RS resources have their own component model and effectively interpret some of the well known annotations like @Inject on their own. Things like Interceptors don't automatically work on JAX-RS resources.

With the micro profile being a new profile, I wonder if it might make sense to investigate how feasible it will be to start out with a JAX-RS variant that's fully CDI based.

Out of the box, Jersey provides HK2, which is JSR-330 compliant, but which is not CDI.

Jersey can bundle Weld for CDI out of the box. It can also run this standalone. I don't know, but I do not believe there is any difference between the JAX-RS + CDI using Jersey/Weld and the environment provided by a standard Jave EE 7 container at the web layer (save for lack of EJBs, etc.).

I am not familiar with other JAX-RS implementations.

Java EE 8 was going to be the consolidating effort to get all of JSF, EJB, JAX-RS, and CDI on the same level playing field in terms of normalizing injection.

So, Jersey + Weld may be a easy access reference platform that doesn't require anyone hacking on a RS implementation or a CDI implementation to make it suitable for our purposes.

Regards,

Will Hartung

[Gunnar Morling]

> would adding a constraint like: "in the micro profile JAX-RS resources are only allowed to be CDI managed beans" be really fractioning?

I'm not sure whether that's feasible really; it remains to be defined what "only allowed" means exactly, but I understand it that in such model "JAX-RS on MicroProfile" wouldn't be as powerful as "JAX-RS as defined in its spec", as certain things wouldn't work. I feel you cannot "take away" something from an existing spec like this.

The story for MVC is a bit different, as they work on their own new spec, and for that they can mandate whatever they wish of course.

[Arjan Tijms]

On Wednesday, July 13, 2016 at 7:38:37 PM UTC+2, Gunnar Morling wrote:

I'm not sure whether that's feasible really; it remains to be defined what "only allowed" means exactly, but I understand it that in such model "JAX-RS on MicroProfile" wouldn't be as powerful as "JAX-RS as defined in its spec", as certain things wouldn't work.

The question is perhaps what exactly wouldn't work anymore, and whether CDI 2.0 (which definitely is active) can fill the gap. Speaking about CDI 2.0, does the micro profile targets CDI 1.2 or 2.0?

You also get things in return btw, like CDI extensions being guaranteed able to modify/enhance JAX-RS resources just like they can any other bean, plus that Interceptors would work out of the box. The latter would be quite a good thing for method level security using a security interceptor.

 

I feel you cannot "take away" something from an existing spec like this.

EJB-lite did ;)

 

The story for MVC is a bit different, as they work on their own new spec, and for that they can mandate whatever they wish of course.

True, so an alternative path *may* possibly be to add a thin (proprietary for now) layer on top of JAX-RS?

Kind regards,

Arjan Tijms

[Werner Keil]

I know as EG member, that JSR 374 (https://jcp.org/en/jsr/detail?id=374) JSON-P has been "reasonably active" and it also produded an EDR 1 last year. So did 365 (https://jcp.org/en/jsr/detail?id=365) where I'm also in the EG. CDI 2 is preparing for EDR 2, it should get one likely around or before JavaOne, at least that's how it sounded in the last conf call with Antoine and other EG members. With that respect JAX-RS (https://jcp.org/en/jsr/detail?id=370) ist clearly the least active (not sure, if it has to do with me not being in the EG, but I can't be in every single one;-) It faced Renewal Ballot and has not published an EDR since. JIRA shows, 1 issue was created in the last 30 days. It's certainly better off than say 373 (with zero ever since;-O) but compared to 365 or 374 it is the least active of the 3 which are mentioned to be rather essential.

It does make the impression, that the same people at Oracle who are involved in MVC 1.0 (https://jcp.org/en/jsr/detail?id=371) including the same Spec Lead are simply overwhelmed with doing 2 JSRs at the same time. Despite being a Spec Lead myself and having a day job I offered help to MVC, but they declined saying "they already have too many people in the EG". Looks like a "sexy, shiny" EG attracted a few more folks and that's why underlying JAX-RS suffers not only the current lack of resources and people at Oracle;-|
Again I can't be in every JSR but I am sure, I wasn't the only one they turned down when they still thought "We can do that on our own"...

Kind Regards,
Werner

[Arjan Tijms]

On Thursday, July 14, 2016 at 10:52:19 AM UTC+2, Werner Keil wrote:

With that respect JAX-RS (https://jcp.org/en/jsr/detail?id=370) ist clearly the least active (not sure, if it has to do with me not being in the EG, but I can't be in every single one;-) It faced Renewal Ballot and has not published an EDR since.

Indeed. Oracle not being active there is perhaps no big surprise given the news, but perhaps the other EG members are just waiting for Oracle and/or have no idea they can also continue for the time being on their own?

It does make the impression, that the same people at Oracle who are involved in MVC 1.0 (https://jcp.org/en/jsr/detail?id=371) including the same Spec Lead are simply overwhelmed with doing 2 JSRs at the same time.

Maybe initially, but currently both spec leads are not doing anything for any of the specs they're leading. So I don't think they're overwhelmed by the JSRs, not at the moment at least.

Kind regards,

Arjan Tijms

[Werner Keil]

Right now it seems totally stalled and for some like 351 they completely pulled the plug. JSON-B either because it's considered of use for some commercial products or because it got a little more done has a Public Draft, everything else looks similar right now.

EG members seem inactive in most cases. Without a clean handover or Spec Lead sharing there are steps even the most dedicated EG members can't do right now. Filing an EDR is reserved to Spec Leads etc.

Btw. unless the baseline for Microprofile was Java SE 8 only, it should be Java EE 7 JSRs for now, otherwise you can no longer use them with SE or EE 7, just take CDI 2 and most others;-)

Kind Regards,
Werner

[Mark Struberg]

I had a chat about this topic with a few people from JAX-RS a while back at the JavaLand conf (Markus Karg, Sebastian Daschner, David Blevins, etc).

My question is why there is no SPI 'Factory' interface in JAX-RS (at least to my knowledge).

It might even be vendor specific.

 

A sample for what I mean can be found in Batch:

https://github.com/apache/incubator-batchee/blob/master/jbatch/src/main/java/org/apache/batchee/spi/BatchArtifactFactory.java

https://github.com/WASdev/standards.jsr352.jbatch/blob/master/com.ibm.jbatch.container/src/main/java/com/ibm/jbatch/spi/services/IBatchArtifactFactory.java

It bascially abstracts away the whole 'factory' part away. The runtime just requests an instance to invoke the target methods on.

Whether the instance you operate on gets provided by EJB, CDI, Class#newInstance() or even Spring does't really matter much, isn't?

LieGrue,

strub

[Arjan Tijms]

Hi,

On Saturday, July 30, 2016 at 9:43:20 PM UTC+2, Mark Struberg wrote:

Whether the instance you operate on gets provided by EJB, CDI, Class#newInstance() or even Spring does't really matter much, isn't?

Do you mean from the framework's point of view or the developer's?

For the developer who has to code the bean it definitely does matter. 

For the framework often not so much. E.g. the framework now does CDI.current().select(Foo.class), but just wants an instance of Foo indeed. On the other hand, a framework may also provide build-in CDI beans which already have say specific interceptors applied to them. In that case those beans have to be obtained via CDI, to else they may not work correctly or at all.

Kind regards,

Arjan Tijms

[Mark Struberg]

> Do you mean from the framework's point of view or the developer's?

I was talking about the integrator/framework perspective.

Of course for the user it does matter whether he likes to use Spring or CDI.

The point I tried to make is that it does not matter that much for the JAX-RS / JAX-WS framework.

It should be technically perfectly possible to use an @ApplicationScoped WebService instead of a @Stateless.

LieGrue,

strub

[Werner Keil]

Aside from other specs like BV MVC builds mostly on JAX-RS.

Most of you may have heard, Oracle plans to hand it to a qualified and capable Spec Lead (or Spec Leads) somewhat similar to Portlet Bridge. Did any of the active participants consider helping out?
When asked some EG members said, it may not be of strategic interest to them or their resources are limited. A few Individuals like Kito or Ivar probably could also be an option, but judging from my own experience with JSR 363 (or the few other cases where Individuals were at least Co-Spec Leads) I thik the only example of a single Individual who succeeded finalizing a JSR with an EG also pretty much with Individual members (Samsung, but they were never active there) was JSR 331.

In all other cases at least one company helped, so the question is, if the MVC spec was of interest to some of the companies involved in Microprofile? (or InnoQ which is also evangelizes the concept of Self-Contained Systems)
Needless to say that for most SCS use cases a UI is at least an optional component, for some it is mandatory, so a UI framework could be handy and MVC seems to have the least overhead on top of the current Microprofile feature JSRs.

Regards,
Werner