[
https://issues.apache.org/jira/browse/CXF-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968908#action_12968908
]
Daniel Kulp commented on CXF-3160:
----------------------------------
Christian,
The situation was that when using WS-Security, we couldn't use
Thread.getContextClassloader().getResourse("/resources/security.properties") or
similar to get the properties files that the application needed to configure
the WS-Security Crypto objects. The thread context classloader was a
classloader just of the CXF bundle, not the application, so the application
specific resources were not available. I was just testing with a "normal"
CXF/JAX-WS service so I may have only encountered that path.
Dan
> Reduce Code duplication between http transport variants
> -------------------------------------------------------
>
> Key: CXF-3160
> URL: https://issues.apache.org/jira/browse/CXF-3160
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Affects Versions: 2.3.0
> Reporter: Christian Schneider
> Assignee: Christian Schneider
> Attachments: CXF-3160-1.patch, CXF-3160-2.patch
>
>
> We still have to much duplicated or very similar code in the http transports.
> Moving header code from AbstractHttpDestination to Headers
> Moving invokeDestination from ServletController to AbstractServletController
> to share this code with http-osgi
> Moving invoke from ServletDestination to AbstractHttpDestination to share
> this code with http-osgi
> Removing doMessage from OsgiDestination
> Removing invokeDestination from OsgiServletcontroller
> Ignoring some mock based tests that do not work anymore. Will have to do some
> work on them
> There are some small changes in the behaviour for http-osgi as we are now
> using the servlet code here. It would be great if Sergey or Dan could review
> this. Idon´t think the differences are important but I am not sure.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
