[
https://issues.apache.org/jira/browse/CXF-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217013#comment-13217013
]
Dave Dixon edited comment on CXF-2838 at 2/27/12 3:17 AM:
----------------------------------------------------------
I'm seeing this problem with cxf 2.5.2 on tomcat 7.0.25 with
StrutsTilesListener, StrutsPrepareAndExecuteFilter mapped to /\*, and cxf
servlet mapped to /services/\*. All requests go to the cxf servlet regardless
of url.
was (Author: ddixon):
I'm seeing this problem with cxf 2.5.2 on tomcat 7.0.25 with
StrutsTilesListener, StrutsPrepareAndExecuteFilter mapped to /*, and cxf
servlet mapped to /services/*. All requests go to the cxf servlet regardless of
url.
> CXFServlet ignores proper ApplicationContext combination loading.
> -----------------------------------------------------------------
>
> Key: CXF-2838
> URL: https://issues.apache.org/jira/browse/CXF-2838
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 2.2.8
> Environment: Windows using Tomcat 5.5/Tomcat 6
> Reporter: Carl Holmes
> Assignee: Daniel Kulp
> Labels: application-context, cxf-servlet
> Fix For: 2.4.2
>
> Attachments: cxf-testcase.zip
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> CXFServlet allows you to specify an init-param element specifying the
> location of an application-context file to be used in combination with the
> root application context (loaded via a ContextLoader(Listener/Servlet) to use
> to construct beans for web services. However, this loading process is not
> done properly.
> Say that a user wished to use the root application context, loaded in the
> ContextLoader(Listener/Servlet) to provide common functionality (database
> beans, cache, email services, etc) between different servlets, but wanted to
> separate out two different sets of web services (that used these common
> beans) and also had another servlet that used these common beans but did not
> expose web services. Normally, that would be done as so:
> context loader listener:
> common application context files
> Servlet#1(CXF servlet #1)
> only web service beans, including the imports for CXF from its META-INF
> directories as desired
> Servlet#2(CXF servlet #2, exposing different web services under a different
> url-pattern than Servlet#1)
> only CXF Servlet #2 web service beans, including the imports for CXF from
> its META_INF directories as desired
> UnrelatedServlet
> Gets the root application context and any additional beans it needs
> Each servlet would then be mapped on different url-patterns, for example,
> /services/*, /securedServices/*, and /.
> However, this doesn't work as expected.
> I traced this down - and it seems that before the context is refreshed, the
> bus is read and a controller is constructed before the servlet gets a chance
> to even read its initialization parameter and append these beans to the Root
> application context to construct a new application context for it to use.
> This isn't a problem for any web application just using an "all beans in the
> context loader listener" or "just web services" approach - but it makes the
> CXFServlet much less useful than it should be. The Root application context
> should be merged with the user-injected specific application context before
> any configuration is attempted.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
