cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: svn commit: r1100162 - /cxf/trunk/rt/core/src/main/java/org/apache/cxf/bus/spring/SpringBus.java
Date Wed, 11 May 2011 00:29:55 GMT
On Tuesday, May 10, 2011 12:40:16 PM Alessio Soldano wrote:
> Hi Willem,
> 
> On 05/10/2011 04:02 PM, Willem Jiang wrote:
> > Hi Alessio,
> > 
> > I checked the code of CXF before I commit the patch, there is no code
> > which set the ClassLoad extension on the bus. I think the patch just
> > bring the issue of ClientImpl::doInvoke() to the table.
> 
> Yes, I agree.
> 
> > The ClassLoader extension is useful in the OSGi environment. If we can
> > set the right TCCL (that could be a application bundle classloader),
> > the application can be a good citizen of the OSGi.
> > 
> > I think that is why CXF 2.4.x ClientImpl::doInvoke did that kind of
> > change. Anyway, it's worth documenting :)
> 
> A "svn blame" tells that change in ClientImpl came in rev.
> ------------------------------------------------------------------------
> r1087406 | dkulp | 2011-03-31 20:40:03 +0200 (Thu, 31 Mar 2011) | 1 line
> 
> Get jaxws:client working in blueprint
> ------------------------------------------------------------------------
> 
> Dan, any insight / opinion here?

I partially explained it in another message sitting in my outbox.  (I'm on a 
cruise ship heading to Bermuda.   Internet is 40 cents a minute for just 
better than dial up speed so I'm relying heavily on "work offline" mode)

Basically, there are a bunch of scenarios where the TCCL needs to be set to 
the applications classloader.   WS-Security requires it for loading the Merlin 
stuff, various SAML2 things, etc...    In addition, getting the correct XML 
parsers, JAX-RS providers, etc... also require it to be properly set.  Spring 
DM made some attempts to set the TCCL to a sane value.  Blueprint does not.   
For blueprint, we had to go through and make sure it's set in the scenarios 
where it's required or at least should be set.   Thus, the Blueprint bus first 
started setting the CL as an extension on the Bus.   With 2.4.0, I think that 
was the only  Bus that set it.   Willem's change makes the SpringBus also do 
so.   I do think that is the correct behavior though.

For the most part, either the Destinations or the message listener on the 
server side should set it prior to calling the chain.   On the client side, 
the invoke method needs to set it.  I DON'T know if all the destinations are 
properly setting it. (which is why doing it in the listener is likely better, 
but it may not be right now)   I was mostly porting a bunch of examples and 
tests from Spring to Blueprint  and making sure they work. 

We don't know if interceptors added to the chain by the client/server need to 
have it set or not (and in the WS-Sec case, it's needed).    For me, the test 
case I was using is the WS=Security examples in the Talend Service Factory 
download.   It uses blueprint for both client and server and to get WSS4J to 
find the correct stuff it needed, the TCCL needed to be set.


-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com

Mime
View raw message