On 24/04/14 11:53, Dolezal, Petr wrote:
Hi Sergey.
I think one solution can be to combine resources and providers from multiple
applications
into a single application and serve it on a single servlet, not sure it will
make sense
in your case though, but this is something I'd try.
I was thinking about this possibility as well. I keep it as the last desperate
solution, because it would make things quite messy.
But yes, the fact we can have multiple applications loaded in the same web.xml
in non-OSGI case points to
the OSGI transport restriction whuch IMHO will need to be addressed.
Let me also look into the possibility of a single JAX-RS servlet supporting
multiple applications...
That would be nice.
I've updated the trunk to support multiple Applications in a single
servlet with the condition that ApplicationPath are not ignored.
Anyway, I just wanted to share yet one more experience which you might be
interesting in. It could mean that there is another kind of sharing
information, possibly expected for you with the knowledge of the CXF internals,
but a bit surprising for a user.
At this moment we split the web applications, each of them maps its JAX-RS
servlet to /*, the JAX-RS applications use ApplicationPath. As described in my
previous post, the (expected) paths for the endpoints are then:
/sessioning/sessioning/
/authz/authz/
If you have multiple web applications with servlet wild card patterns
only then you won't have this duplication.
Also, with the fix which has just went into the trunk you'd be able to
have a single wildcard servlet with the javax.ws.rs.Application
parameter having a comma separated list of application classes, which
will also make it possible to fix the duplication.
Sergey
When the server is freshly started, acessing /sessioning/sessioning/ shows a
page with a link to WADL of endpoint. Acessing /authz/authz/ shows a page with
links to WADL for both endpoints. After that accessing /sessioning/sessioning/
again shows also a page with the two links. Well, this is just funny. However,
these paths work then too:
/sessioning/authz/
/authz/sessioning/
The last path element matters in selecting the actual service, the path of the
hosting web application is not significant.
But! With lazy servlet loading these "swapped" paths work only after accessing the original
"unswapped" paths. When load-on-startup forces the servlets to activate, the "unswapped"
paths work immediately. (No, I'm not really thinking of abusing this glitch ;-) although I must admit that
this idea came to my mind.)
Bye,
Petr
