There's also an unwritten "if you don't rule it out, someone
will do it" paradigm. ;-)
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
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)
_______________________________________________
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