You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Christian Schneider (JIRA)" <ji...@apache.org> on 2011/02/17 13:25:24 UTC
[jira] Created: (CXF-3343) Make servlet component compatible with a
application context initialized with the contextloaderlistener
Make servlet component compatible with a application context initialized with the contextloaderlistener
-------------------------------------------------------------------------------------------------------
Key: CXF-3343
URL: https://issues.apache.org/jira/browse/CXF-3343
Project: CXF
Issue Type: Improvement
Reporter: Christian Schneider
When using the servlet component we currently require that the applicationcontext is defined in the CamelHttpServlet like shown in:
https://svn.apache.org/repos/asf/camel/trunk/components/camel-servlet/src/test/resources/org/apache/camel/component/servlet/web-spring.xml
We should find a way to make the servlet component work with an applicationcontext that is loaded using the spring ContextLoaderListener.
When working in OSGi with the servlet component I had the idea to not use a single CamelHttpServlet but to register a servlet just when the endpoint starts and exactly with the uri specified in the endpoint. This would solve the problem of finding the CamelHttpServlet and would also allow us to reserve paths in the webserver more fine grained.
E.g. at the moment it is not easily possible to have a servlet on /test1 and one on /test2 while some other non camel servlet on the server uses /test3. With the aproach described it would be no problem.
The main problem with the aproach that I see is that it would be slightly incompatible with the current aproach as a servlet endpoint servlet:///test with a url of test1 for the servlet at the moment results in /test1/test. With the new aproach it would always be at /test. We could make this more compatible if the servlet component can be initialized with a prefix (test1 in that case).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CXF-3343) Make servlet component compatible with
a application context initialized with the contextloaderlistener
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12996327#comment-12996327 ]
Sergey Beryozkin commented on CXF-3343:
---------------------------------------
Hi Christian
When you mention the incompatibility, are you referring to the way your proposed changes can effect the Camel CXF component or the CXF alone too ?
Just would like to understand the possible side-effects better in order to avoid JAX-RS-related issues
thanks
> Make servlet component compatible with a application context initialized with the contextloaderlistener
> -------------------------------------------------------------------------------------------------------
>
> Key: CXF-3343
> URL: https://issues.apache.org/jira/browse/CXF-3343
> Project: CXF
> Issue Type: Improvement
> Reporter: Christian Schneider
>
> When using the servlet component we currently require that the applicationcontext is defined in the CamelHttpServlet like shown in:
> https://svn.apache.org/repos/asf/camel/trunk/components/camel-servlet/src/test/resources/org/apache/camel/component/servlet/web-spring.xml
> We should find a way to make the servlet component work with an applicationcontext that is loaded using the spring ContextLoaderListener.
> When working in OSGi with the servlet component I had the idea to not use a single CamelHttpServlet but to register a servlet just when the endpoint starts and exactly with the uri specified in the endpoint. This would solve the problem of finding the CamelHttpServlet and would also allow us to reserve paths in the webserver more fine grained.
> E.g. at the moment it is not easily possible to have a servlet on /test1 and one on /test2 while some other non camel servlet on the server uses /test3. With the aproach described it would be no problem.
> The main problem with the aproach that I see is that it would be slightly incompatible with the current aproach as a servlet endpoint servlet:///test with a url of test1 for the servlet at the moment results in /test1/test. With the new aproach it would always be at /test. We could make this more compatible if the servlet component can be initialized with a prefix (test1 in that case).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira