I never came across any technical *need* to put more than one application into one WAR, neither could anybody so far explain to me why we *want* to do that, as it is pretty simple to link two WARs to one shared utility JAR. For me there always was that unwritten paradigm of a WAR being the package around *one* application.
Just my 2c.
-Markus
From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Ron Sigal
Sent: Dienstag, 8. Januar 2019 00:56
To: jaxrs-dev@xxxxxxxxxxx
Subject: Re: [jaxrs-dev] Request for extension with Application interface
Hi Christian and Santiago,
Thanks for your responses. It seems that we're all on the same page at least as far as agreeing that further clarification is called for.
1. One question is: How common in practice is it for a WAR to contain more than one Application? In the RESTEasy issue I mentioned, "Same JAX-RS Application instance injected across applications" (https://issues.jboss.org/browse/RESTEASY-1709), the reporter said, when asked for sample code, "I'll try to put together something simpler, for a number of reasons: not supposed to post internal code publicly, too large and complex etc.". That suggests that the question arose from a real application. I'm sure there are people on this mailing list that have some sense of the answer.
2. If, in fact, it is somewhat common, then some people would be unhappy if the JAX-RS spec ruled it out. I guess the only options would be
A. Leave things as they are
B. Formalize the whole thing
3. If the decision is to formalize multiple Applications in a WAR, then I think it would require defining a "JAX-RS Application Scope" as per section 2.4.2 "Defining new scope types" of JSR 365 Contexts and Dependency Injection for Java 2.0.
Thanks,
Ron
On 1/7/19 1:45 PM, Santiago Pericas-Geertsen wrote:
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?
I sincerely doubt that, at least at the beginning, there was any intent to support more than one Application instance. There are a number of areas which would need to be clarified if multiple instances were supported (an example would be automatic discovery of resources/providers). I can see how this use case is becoming more appealing, but I don’t think it is a portable feature at the moment.
The premise of this request is the existence of more than one Application instance. I think this premise should be discussed first to make sure everyone is on the same page. I also agree with the CDI comments made by others.
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jaxrs-dev
--
My company's smarter than your company (unless you work for Red Hat)
