cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CXF-6132) Provide JAX-RS ServletContextInitializer
Date Fri, 16 Jan 2015 12:40:35 GMT

    [ 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)

Mime
View raw message