Actually, as it happens, Christian has done a brilliant job in
introducing a bundle activator for initializing the default HTTP OSGi
transport and at this point of time we can simply support a property
optionally disabling the default CXF OSGI transport.
I've introduced an
"org.apache.cxf.osgi.http.transport.disable" property, set it as the
system container property and it should make the original issue going away.
I think we are doing well here...
Sergey
On 24/04/14 13:40, Sergey Beryozkin wrote:
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
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
