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 [email protected] http://dankulp.com/blog Talend - http://www.talend.com
