[
https://issues.apache.org/jira/browse/CXF-6132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14280166#comment-14280166
]
Sergey Beryozkin edited comment on CXF-6132 at 1/16/15 12:40 PM:
-----------------------------------------------------------------
Hi Andriy,
I guess we need to have the container to provide ApplicationPath, Path and
Provider annotated classes. If an ApplicationPath class is available then we
can simply ignore Path and Provider annotated classes because ApplicationPath
points to Application which will set up everything. If ApplicationPath class is
not available then we'd create a new Application instance from those Path and
Provider classes.
What is not clear to me yet is how to register CXFNonSpringJaxrsServlet - I
think we can register it as as a servlet filter against with the provided
ServletContext.
The other thing that I'm not sure about is whether the code implementing JAX-RS
ServletContextInitializer should be shipped in a sep module or not. The
possible issue here is that if we ship it statically with the JAX-RS frontend
then it might cause side-effects in cases where people do provide web.xml with
CXFNonSpringJaxrsServlet declared, so we might have a double registration if a
container also supports ServletContextInitializer. I guess, as POC, it can be
added to 3.1.0-SNAPSHOT rt/frontend/jaxrs first just to make thing simpler, but
then we'd need to make the final decision before 3.1.0 gets out, which is still
some time away...
Thanks
was (Author: sergey_beryozkin):
Hi Andriy,
I guess we need to have the container provided ApplicationPath, Path and
Provider annotated classes. If an ApplicationPath class is available then we
can simply ignore Path and Provider annotated classes because ApplicationPath
points to Application which will set up everything. If ApplicationPath class is
not available then we'd create a new Application instance from those Path and
Provider classes.
What is not clear to me yet is how to register CXFNonSpringJaxrsServlet - I
think we can register it as as a servlet filter against with the provided
ServletContext.
The other thing that I'm not sure about is whether the code implementing JAX-RS
ServletContextInitializer should be shipped in a sep module or not. The
possible issue here is that if we ship it statically with the JAX-RS frontend
then it might cause side-effects in cases where people do provide web.xml with
CXFNonSpringJaxrsServlet declared, so we might have a double registration if a
container also supports ServletContextInitializer. I guess, as POC, it can be
added to 3.1.0-SNAPSHOT rt/frontend/jaxrs first just to make thing simpler, but
then we'd need to make the final decision before 3.1.0 gets out, which is still
some time away...
Thanks
> Provide JAX-RS ServletContextInitializer
> -----------------------------------------
>
> Key: CXF-6132
> URL: https://issues.apache.org/jira/browse/CXF-6132
> Project: CXF
> Issue Type: New Feature
> Components: JAX-RS
> Reporter: Sergey Beryozkin
> Assignee: Andriy Redko
> Fix For: 3.0.4, 3.1.0
>
>
> This will offer an advanced support for the auto-discovery of JAX-RS
> Application, root resources and providers in OSGI in combination with
> pax-web-jetty.
> Options:
> - dynamically register the implementation as OSGI service
> - ship a static implementation
> [1]
> https://github.com/ops4j/org.ops4j.pax.web/blob/master/pax-web-jetty/src/main/java/org/ops4j/pax/web/service/jetty/internal/JettyServerWrapper.java#L303
> [2]
> http://docs.oracle.com/javaee/7/api/javax/servlet/ServletContainerInitializer.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
