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
