|
On 1/8/19 12:21 AM, Christian Kaltepoth wrote:
Hi Ron,
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.
In one of my current projects I'm also using two JAX-RS
applications within a single WAR. Mostly because there are
two different types of resources:
- There is an API called from another Java application
with exposes data and enforces a special kind of
stateless authentication
- And there are resources for the _javascript_-based
frontend which require session-based authentication.
As I need different exception mappers and filters for
both kinds of resources, it was the easiest solution to
use two Application subclasses and list the corresponding
resources/providers via Application.getClasses().
May I ask which implementation of JAX-RS you're using? And, if
it's not RESTEasy, do you know if it handles @Context injection of
Applications correctly?
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
What about (C)? Making it optional by saying: "JAX-RS
implementations MAY support more than one JAX-RS application
within a single deployment unit"
I propose a new meta-rule: There's always a C. ;-)
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.
Agreed.
Christian
--
_______________________________________________
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)
|
