Hi Lars-Fredrik
Yes, a new Application instance is created per every CXF servlet
Cheers, Sergey
On 13/07/16 22:47, Lars-Fredrik Smedberg wrote:
Hi
@Sergey yes I will file a PMR about this, will keep you updated.
In your case will each servlet instance get its seperate instance of the
Application subclass? I guess they need to get that since (if I remember
correct) the spec allows me to inject e.g. a ServletConfig instance in the
constructor using @Context....
Regards
Lars-Fredrik
On Wed, Jul 13, 2016 at 6:15 PM, Sergey Beryozkin <[email protected]>
wrote:
I got a bit confused there myself.
Just modified this CXF test resource:
https://github.com/apache/cxf/blob/master/systests/jaxrs/src/test/resources/jaxrs_non_spring/WEB-INF/web.xml
specifically, removed all servlets but left CXFServlet2 & CXFServlet5:
https://github.com/apache/cxf/blob/master/systests/jaxrs/src/test/resources/jaxrs_non_spring/WEB-INF/web.xml#L59
and
https://github.com/apache/cxf/blob/master/systests/jaxrs/src/test/resources/jaxrs_non_spring/WEB-INF/web.xml#L122
Note CXFServlet2 uses "application/*" & CXFServlet5 - "application11/*"
patterns. Both refer to the same application class:
https://github.com/apache/cxf/blob/master/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/BookApplication.java
CXFServlet5 is also configured to not ignore ApplicationPath on this
class, which is "/thebooks" - so I removed it for the purpose of the test.
Next I run this test:
https://github.com/apache/cxf/blob/master/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSClientServerNonSpringBookTest.java#L73
this is covered by CXFServlet2, and next I run
https://github.com/apache/cxf/blob/master/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSClientServerNonSpringBookTest.java#L168
but removed "/thebooks" from its request URI, all works OK.
Each CXFNonSpringJaxrsServlet has its own CXF Bus which is internal
container of various extensions/features and endpoints. Given that each
servlet has a unique Bus, the fact that the same Application is reused is
OK.
It is def an issue with the IBMServlet or rather the way
CXFNonSpringJaxrsServlet is extended or modified there. For example, if
each CXFNonSpringJaxrsServlet will share the same Bus there then the
problem I described earlier will arise. Etc. So makes sense raising an
issue at the web sphere forums. Let me know how it goes please
Thanks, Sergey
On 13/07/16 16:17, Lars-Fredrik Smedberg wrote:
@Serget thanks for the update... will this happen even if each servlet is
mapped to a different url-pattern using <servlet-mapping..../>
I though the Application subclass got a call to its getClasses method for
each REST servlet setup? My thoughts was to depending on e.g.
init-parameters return a subset of the root resources (@Path annotated
classes...) I found during annotation scanning (Extension...) or by
configuration.... That way the same Application subclass could be used but
return different classes depending on the servlet it was called from....
Is the thinking wrong?
The reason for doing this has to do mostly with responsibilities within
the
company when it comes to development, configuration and deployment....
Regards
LF
On Wed, Jul 13, 2016 at 12:12 PM, Sergey Beryozkin <[email protected]>
wrote:
Hi
Right. @ApplicationPath is expected to be ignored anyway when the
application is wired in via a servlet. I thought a bit more about it.
Each CXF endpoint typically uses a relative endpoint address, "/" by
default.
For example, if you have a Servlet pattern such as "/services/*"
and a single Application then the root endpoint address is say
"http://localhost:8080/services";
When you add another servlet with the same Application, a new endpoint is
created with the same default relative "/" path, with one of the two
endpoints being lost.
At a CXF level it can be solved by supplying an additional servlet
parameter, "jaxrs.address" which is set to something like "/a" etc.
FYI, I think it is quite rare to have the same Application deployed under
multiple servlets. Not sure at all it will work with other
implementations.
So try "jaxrs.address", if it proves not ideal then consider having a
single Application with multiple root resources, with each root resource
having a unique Path, etc
HTH, Sergey
On 13/07/16 09:42, Lars-Fredrik Smedberg wrote:
Hi
@Sergey, thanks for your answer... see some follow ups inline
Regards
LF
On Mon, Jul 11, 2016 at 1:00 PM, Sergey Beryozkin <[email protected]
wrote:
Hi
Please see comments inline
On 10/07/16 16:03, Lars-Fredrik Smedberg wrote:
Hi!
To be able to expose different root resources for different paths I
have
defined my REST servlet
(com.ibm.websphere.jaxrs.server.IBMRestServlet,
running WLP 8.5.5.9 which to my understanding uses CXF) multiple times
with
different servlet-mappings.
I tried to specify the same jaxax.ws.rs.Application class for both
servlet
mappings (it works out internally what root resources to expose) using
an
init-parameter:
<init-param>
<param-name>javax.ws.rs.Application</param-name>
<param-value><FQCN></param-value>
</init-param>
I tried to define my REST servlet two times using different mappings
but
with the same init-parameter for the Application class.
When I do this I get the following FFDC log when calling resources on
one
of the mappings but not the other.
com.ibm.ws.webcontainer.webapp.WebAppErrorReport:
javax.servlet.UnavailableException: SRVE0200E: Servlet
[com.ibm.websphere.jaxrs.server.IBMRestServlet]: Could not find
required
class - com.ibm.websphere.jaxrs.server.IBMRestServlet
When using two different Application subclasses I do not get this
error.
Questions:
- Is this something IBM or CXF related?
when you have Application registered like this then as far as I know
its
@ApplicationPath, it it exists, is ignored in favor of the servlet URL
pattern, so I think it may be an IBM issue, because if you have two
servlets with diff URL patterns referring to the same Application then
it
should work just fine.
I'm not using the @ApplicationPath annotation but rather map each
servlet
to an url in the web.xml
The fact that one of servlets is not visible implies that
@ApplicationPath
is not ignored, and is used as some kind of a key, and it causes the
issues.
- Is it suppose to work with the same Application subclass for multiple
defined REST servlets? Workarounds if not?
IMHO it should work. Try the existing workaround (with two subclasses)
for
now
Cheers, Sergey
Regards
Lars-Fredrik
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
