Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jaxrs-dev] Request for extension with Application interface
Hi Ron,

Actually, I think it's worth mentioning that the JAX-RS spec is a little murky on this subject. When it says, "By default a single instance of each provider class is instantiated for each JAX-RS application", it seems to be indirectly defining "JAX-RS application scope" as being the time during which a resource from a particular Application is running, which would be different than the servlet notion of application scope.

Well, IMO the quoted sentence from the spec is very clear. Provider classes are created per JAX-RS application. So if you have a provider annotated with @Provider and two Application classes, you will end up with two instances of this provider. And yes, this is some kind of JAX-RS application scope if you would describe it in CDI terms.

However, I agree that things get more complicated if you include CDI. And I agree that the spec isn't very clear about how CDI integration works in detail. We really need to clarify this.
 

In the discussion in https://issues.jboss.org/browse/RESTEASY-1709 "Same JAX-RS Application instance injected across applications", someone questioned whether it was even legal to have two Applications in a single WAR. It does seem to be legal, but it would be good if the spec were clearer.

I don't see why having multiple Application classes in a single WAR should not be allowed. However, I also agree that some clarification would be great.

Also, it feels weird to add an interface which is basically the same as the existing Application class. This doesn't bring any benefit for the user from an API perspective. It looks like it just addresses an implementation concern.

Yeah, fair enough. Really, I'm thinking that Application should have been defined as an interface in the first place, which would make it consistent with all of the other @Context injectible types. Clearly, it's too late to turn Application into an interface, so I was just thinking of a possible solution.

Yeah, maybe an interface would have been a better option. But maybe there are good arguments for a class that I'm not aware of?

And actually using Javassist in these situations is very common. Therefore, I'm unsure if we should really address this on the spec level.

Ok, I cant argue against that. It's just that all of our @Context injections are done with java proxies, and then there's a completely differently treatment for Applications. Like Warren Zevon said, "It ain't that pretty at all".

Agreed. I would really love to deprecate @Context soon. CDI is a great component model and @Context clearly has many weaknesses.

Christian



--
Christian Kaltepoth

Back to the top