|
Hi Santiago,
Looking back at all that I've read and written on the subject, I
suspect that "spec does not appear to prevent" evolved into "spec
appears to support" in my mind.
In https://issues.jboss.org/browse/RESTEASY-1709,
it was noted that the sentence "By default a single instance of
each provider class is instantiated for each JAX-RS application,"
appearing in Section 4.1 of the spec, seems to allow for multiple
JAX-RS applications *somewhere*. Reading it again, I feel less
convinced.
It's interesting to note that in JIRA issue "RESTeasy does not
allow multiple Applications in the same webapp"
(https://issues.jboss.org/browse/RESTEASY-650), Bill Burke says
(in 2012), "I thought (and made the assumption) that you could
have only one Application class." But then he went ahead and made
multiple Applications possible. In fact, RESTEASY-650 grew out of
Wildfly issue "RESTEasy: Can't deploy WebApp if more than one
subclass of javax.ws.rs.Application is present"
(https://issues.jboss.org/browse/WFLY-831), which refers to the
sentence "It is an error
for more than one application to be deployed at the same effective
servlet mapping" that appears in Section 2.3.2 "Servlet" of the JAX-RS
1.1 spec. That would seem to imply that multiple
Applications are legal otherwise. Of course, that sentence was
removed in JAX-RS 2.0.
So there appears to be a history of confusion on the subject, but
I have to say that now I think you're right.
The question remains whether multiple Applications in a WAR is a
useful feature.
-Ron
On 1/9/19 9:10 AM, Santiago
Pericas-Geertsen wrote:
Hi Ron,
Hi Markus,
When I made my request, I didn't know that
1. the existence of multiple Applications in a WAR would
be considered controversial, since the spec appears to
support it, and that
I’m not sure I agree with the statement “the spec appears to
support it”. Where? In fact, it often refers to the Application
class in singular form, instead of saying “for each Application
instance then …”. If you meant, the “spec does not appear to
prevent this”, then I would agree.
As I stated before, there would be a number of sections that
would need updating if that was formally supported.
— Santiago
2. there was an inclination to deprecate @Context.
My intention was to simplify and
regularize the @Context injection of Applications. If
@Context injection is deprecated, and I gather that that
is likely, then my request is moot and I'm happy to let it
go.
What remains is to determine what to do
about multiple Applications in a WAR. I guess my position
would be:
1. Please don't outlaw multiple Applications, since
RESTEasy already supports that (though, because of the
@Context issue, not entirely correctly).
2. At the very least, offer a warning about the pitfalls
if an implementation of JAX-RS chooses to support multiple
Applications.
As for "a good argument why one needs to have
two applications in one single WAR", there
seem to be some existence arguments floating around (e.g., https://issues.jboss.org/browse/RESTEASY-1709)
and a couple of allusions on this mailing list.
Personally, I haven't made any such argument, though.
-Ron
On 1/9/19 1:16 AM,
Markus KARG wrote:
There is also an unwritten rule that we try
to use reasonable arguments in
this mailing list. ;-) I can remember several
discussions where someone badly wanted to see his
feature of choice being standardized and shorty
after rejected his proposal when he finally learned
that it is not needed or even useful at all. Having
said that, I'm still waiting for a good argument why
one needs to have two applications in one single WAR
other than "He just wants it" so we can go on with
the discussion on a more solid base.
-Markus
There's also an
unwritten "if you don't rule it out, someone will do
it" paradigm. ;-)
On 1/8/19 1:30 PM, Markus KARG wrote:
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
--
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
--
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
_______________________________________________
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)
|
