You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Daniel Kulp <dk...@apache.org> on 2011/06/21 23:34:38 UTC
CAMEL-4135/4109 and Spring and Blueprint namespace things....
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
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: CAMEL-4135/4109 and Spring and Blueprint namespace things....
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: CAMEL-4135/4109 and Spring and Blueprint namespace things....
Posted by Willem Jiang <wi...@gmail.com>.
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.
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: CAMEL-4135/4109 and Spring and Blueprint namespace things....
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: CAMEL-4135/4109 and Spring and Blueprint namespace things....
Posted by Johan Edstrom <se...@gmail.com>.
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 :) ...
/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
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com