I've started a bit of this in CAMEL-4139 I got rid of the CxfEndpointBean (and the spring subclass) and updated the spring stuff to parse directly into the CxfEndpoint. I've added setters/getters for the various things that the parsers need to support. This now unifies the Blueprint and Spring versions and should allow the blueprint version to actually support interceptors/features/etc...
The next step in my cleanup would be to move CxfBlueprintEndpoint into blueprint subpackage and CxfSpringEndpoint into spring. That should keep things a bit cleaner. At that point, the only spring related thing outside the spring package would be the doGetBus call on CxfEndpoint. I need to look at that a bit more to understand if that can likewise be moved a bit. Dan On Wednesday, June 22, 2011 11:51:00 AM Willem Jiang wrote: > CxfEndpointBean is used to take the configuration of CXF > ServiceFactoryBean which is used to configure CXF endpoints. > > In this way, the user can reuse their knowledge of CXF client or server > configuration on the configuration of camel-cxf endpoint. > > You can configure interceptor, features, handler through the Spring > configuration, but you can't do it through the camel-cxf URI in current > camel-cxf component. > > I agree CxfEndpointBean has a strong dependency on the Spring and we > should avoid it. > > Maybe we could do some refactoring and enhancement in the feature to > support the configuration of interceptor and features from URI. > > On 6/22/11 6:18 AM, Daniel Kulp wrote: > > On Tuesday, June 21, 2011 3:47:48 PM Johan Edstrom wrote: > >> At the time I wrote that, > >> I was trying to get around what was happening on the > >> Spring side, and cut it down as much as possible. > >> > >> I am pretty sure that I had sane reasoning at some point :) ... > > > > Looking into it a little bit more, I really think the blueprint way of > > doing it is much closer to "correct". CxfEndpointBean implements all > > the Spring interfaces. Thus, it really wouldn't be appropriate for > > the blueprint stuff to create that. What's worse, since CxfComponent > > does an "instanceof CxfEndpointBean", that means CxfComponent REQUIRES > > the spring jars on the classpath. Things definitely need some cleanup > > around all of this. :-( > > > > Still digging...... > > > > Dan > > > >> /je > >> > >> On Jun 21, 2011, at 3:34 PM, Daniel Kulp wrote: > >>> Just a quick question... > >>> > >>> I'm working on some CXF blueprint stuff with Camel and ran into a > >>> little issue that I want to discuss real quick. There is a slight > >>> difference between how blueprint and spring parse the namespace. > >>> I just want to see if they should be unified a bit. > >>> > >>> Basically, the Spring namespace handler parses into a > >>> "CxfEndpointBean" > >>> (well a subclass of) and then the CxfComponent then will look that > >>> up > >>> and convert that into a CxfEndpoint. > >>> > >>> Blueprint, on the other hand, parses directly to a CxfEndpoint. I > >>> had > >>> to make some slight modification to the CxfComponent to take that > >>> into > >>> account. The patch I stuck on CAMEL-4135 handles that. However, > >>> I'm not sure that's the best route. Do you think the blueprint > >>> stuff > >>> should parse into a CxfEndpointBean as well? I'm still kind of > >>> digging into the camel-cxf stuff and haven't quite gotten a handle > >>> around the differences. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
