Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of willem.jiang@gmail.com
 designates 209.85.210.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=pqIXkWUtE6yWXQQaG+52gMCDimRNeHiGJjslFE5qPQ51m4faYPseQwShqvKUrVb3x+
         d1qcoFwPM2kW+zyp3SgLszeSKF0yfVZiO9KWmbUgnvbjPPwAXjlE9etZ6j2mtIjVMq9s
         9pxfeOXhhaecN5CivJIZ2hbcZReDZnN2/RmSE=
Message-ID: <4E0166A4.5020707@gmail.com>
Date: Wed, 22 Jun 2011 11:51:00 +0800
From: Willem Jiang <willem.jiang@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: dev@camel.apache.org
Subject: Re: CAMEL-4135/4109 and Spring and Blueprint namespace things....
References: <3540897.7dX9QsKWBo@dilbert.dankulp.com>
 <C73A9608-E097-4144-9E9D-BEEB9F423FD2@gmail.com>
 <18180207.WMno5Q63YY@dilbert.dankulp.com>
In-Reply-To: <18180207.WMno5Q63YY@dilbert.dankulp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


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