|
Thanks, Markus. Fair enough.
On 1/9/19 7:03 AM, Markus KARG wrote:
Given
the current status of the various discussions I assume we
will do your point #1 as I cannot remember somebody wanted
to explicitly *forbid* multiple applications; IIRC the
proposal was to write "MAY". For point #2 this is tricky, as
adding warnings to the specification might open the
question, how long the list of warnings shall become. If the
API or spec is not clear, we should clarify it, not append
explicit warnings to unclear sections. So once we write "A
compliant product MAY support multiple applications in one
WAR file." no such warning should be needed.
-Markus
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
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
--
My company's smarter than your company (unless you work for Red Hat)
|
