camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott England-Sullivan <sully6...@gmail.com>
Subject Re: Dependencies of camel-spring
Date Mon, 15 Oct 2012 12:36:35 GMT
Sorry Benjamin. I will have to do some further research. Thanks for the clarification. 

Best Regards,
Scott ES

On Oct 15, 2012, at 7:20 AM, "Benjamin Graf" <Benjamin.Graf@gmx.net> wrote:

> Hi Scott,
> 
> some last comments from me.
> 
> Regards,
> Benjamin
> 
> -------- Original-Nachricht --------
>> Datum: Sun, 14 Oct 2012 16:52:05 -0500
>> Von: Scott England-Sullivan <sully6768@gmail.com>
>> An: dev@camel.apache.org
>> Betreff: Re: Dependencies of camel-spring
> 
>> In summary and to close out:
>> 
>> * Post to Camel User
>> Please use the Camel User mailing list for usage questions and issues.
>> 
>> 
>> * JBoss Issue:
>> 
>> Within JBoss you willhave better success using the JBoss Snowdrop
>> project.  There are a number of threads that discuss using it on the
>> forums and on google.  Details can be found here:
>> https://www.jboss.org/snowdrop
> 
> No option if you want proper lifecycle an dependency management. Like OSGi or JBI in
older days.
> 
>> 
>> 
>> * Gemini Blueprint:
>> 
>> Spring DM != Gemini Blueprint
> 
> Gemini Blueprint = Spring DM v2 + x
> 
>> 
>> Gemini Blueprint != Spring
> 
> Gemini Blueprint = Spring + x
> 
>> 
>> There is a loose relationship there but they really are two different
>> things.
> 
> Not right at all. Gemini does completly depend on the Springframework API
> 
>> 
>> What you are looking for is support for the OSGi Blueprint provider
>> Eclipse Gemini in Camel.  Blueprint support is currently included in
>> the camel-blueprint project. The camel-blueprint project currently
>> only offers support for Aries Blueprint.  What is required is Eclipse
>> Gemini support by either inclusion in the camel-blueprint project or a
>> completely new project camel-blueprint-gemini.
>> 
>> Upgrading to camel-spring Eclipse Gemini isn't an option because it is
>> the home Spring DM which is fully dependent on the Spring APIs.
>> 
>> My first preference would be for the camel-blueprint project to be
>> able to support any underlying OSGi Blueprint provider over having a
>> secondary project.
>> 
>> There is already some work happening WRT to your request under
>> CAMEL-4543.  If you have a patch that would provide the underlying
>> support for Eclipse Gemini please attach it there.  If not, add
>> yourself as a watcher to the ticket to be updated of any progress.
>> 
>> https://issues.apache.org/jira/browse/CAMEL-4543
> 
> As mentioned before Spring OSGi (Spring DM) and Eclipse Gemini both react to the same
namespaces in XML config files. That's why you won't be able to use camel-spring and any gemini
blueprint camel component together since you will have to install two OSGi handlers to fulfill
dependencies.
> 
>> Best Regards,
>> Scott ES
>> 
>> 
>> On Fri, Oct 12, 2012 at 9:42 AM, Benjamin Graf <benjamin.graf@gmx.net>
>> wrote:
>>> By the way. Any more comments on the root topic? ;-)
>>> 
>>> 
>>> 
>>> Scott England-Sullivan <sully6768@gmail.com> schrieb:
>>> 
>>>> Will post back here with results later on.
>>>> 
>>>> On Oct 11, 2012, at 8:35 PM, Willem jiang <willem.jiang@gmail.com>
>>>> wrote:
>>>> 
>>>>> Hi Scott,
>>>>> 
>>>>> I just checked karaf 2.3.0 which is on vote now is using Aries
>>>> blueprint 1.0.0 now.
>>>>> If you want to do some verification, you could use that one.
>>>>> 
>>>>> --
>>>>> Willem Jiang
>>>>> 
>>>>> Red Hat, Inc.
>>>>> FuseSource is now part of Red Hat
>>>>> Web: http://www.fusesource.com | http://www.redhat.com
>>>>> Blog: http://willemjiang.blogspot.com
>>>> (http://willemjiang.blogspot.com/) (English)
>>>>>         http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
>>>>> Twitter: willemjiang
>>>>> Weibo: willemjiang
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Friday, October 12, 2012 at 9:08 AM, Willem jiang wrote:
>>>>> 
>>>>>> Yeah, I think we could consider to upgrade the camel-blueprint to
>>>> Aries 1.0.0 in Camel 2.11.0.
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Willem Jiang
>>>>>> 
>>>>>> Red Hat, Inc.
>>>>>> FuseSource is now part of Red Hat
>>>>>> Web: http://www.fusesource.com | http://www.redhat.com
>>>>>> Blog: http://willemjiang.blogspot.com
>>>> (http://willemjiang.blogspot.com/) (English)
>>>>>> http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
>>>>>> Twitter: willemjiang
>>>>>> Weibo: willemjiang
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Thursday, October 11, 2012 at 11:17 PM, Scott England-Sullivan
>>>> wrote:
>>>>>> 
>>>>>>> Willem,
>>>>>>> 
>>>>>>> Following this I was about to ask when it would make sense
>>>> upgrading camel-blueprint to Aries 1.0.0.
>>>>>>> 
>>>>>>> My concern is I believe Aries 1.0.0 breaks backwards capability
(I
>>>> will verify). Therefore is it something that we can upgrade for Camel
>>>> 2.x or does it need to go on the roadmap for Camel 3.0?
>>>>>>> 
>>>>>>> Best Regards,
>>>>>>> Scott ES
>>>>>>> 
>>>>>>> On Oct 11, 2012, at 8:42 AM, Willem jiang <willem.jiang@gmail.com
>>>> (mailto:willem.jiang@gmail.com)> wrote:
>>>>>>> 
>>>>>>>> FYI, Aries Blueprint 1.0 was released.
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Willem Jiang
>>>>>>>> 
>>>>>>>> Red Hat, Inc.
>>>>>>>> FuseSource is now part of Red Hat
>>>>>>>> Web: http://www.fusesource.com | http://www.redhat.com
>>>>>>>> Blog: http://willemjiang.blogspot.com
>>>> (http://willemjiang.blogspot.com/) (English)
>>>>>>>> http://jnn.javaeye.com (http://jnn.javaeye.com/) (Chinese)
>>>>>>>> Twitter: willemjiang
>>>>>>>> Weibo: willemjiang
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Thursday, October 11, 2012 at 7:00 PM, Benjamin Graf wrote:
>>>>>>>> 
>>>>>>>>> Hi Willem,
>>>>>>>>> 
>>>>>>>>> camel-blueprint is no option for me since it uses Aries
blueprint
>>>> which does not work correctly with jndi in boss OSGi. That is the
>>>> reason why I switched back to spring recognizing that it's outdated.
>>>> Anyway the fact that Aries does not yet reached a 1.0 release makes it
>>>> not well suited for a commercial application in my opinion.
>>>>>>>>> 
>>>>>>>>> Benjamin
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Willem jiang <willem.jiang@gmail.com
>>>> (mailto:willem.jiang@gmail.com)> schrieb:
>>>>>>>>> 
>>>>>>>>>> camel-blueprint is suppose to do the OSGi related
work this
>>>> time.
>>>>>>>>>> 
>>>>>>>>>> You may consider to use it to get ride of the dependencies
of
>>>>>>>>>> camel-spring.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Willem Jiang
>>>>>>>>>> 
>>>>>>>>>> Red Hat, Inc.
>>>>>>>>>> FuseSource is now part of Red Hat
>>>>>>>>>> Web: http://www.fusesource.com | http://www.redhat.com
>>>>>>>>>> Blog: http://willemjiang.blogspot.com
>>>>>>>>>> (http://willemjiang.blogspot.com/) (English)
>>>>>>>>>> http://jnn.javaeye.com (http://jnn.javaeye.com/)
(Chinese)
>>>>>>>>>> Twitter: willemjiang
>>>>>>>>>> Weibo: willemjiang
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Thursday, October 11, 2012 at 1:10 PM, Benjamin
Graf wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hi Christian,
>>>>>>>>>>> 
>>>>>>>>>>> the issue is that Gemini has a different packaging
and camel
>>>> spring
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> has a dependency which tries to load classes from
spring OSGi
>>>> when
>>>>>>>>>> activator in manifest is triggered. Unfortunately
it is not drop
>>>> in
>>>>>>>>>> replacement. :-(
>>>>>>>>>>> 
>>>>>>>>>>> I would suggest to update dependency in spring
module or remove
>>>> OSGi
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> code to a new camel spring OSGi module and introduce
a new camel
>>>> Gemini
>>>>>>>>>> blueprint module.
>>>>>>>>>>> 
>>>>>>>>>>> Benjamin
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> "Christian Müller" <christian.mueller@gmail.com
>>>> (mailto:christian.mueller@gmail.com)
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> (mailto:christian.mueller@gmail.com)> schrieb:
>>>>>>>>>>> 
>>>>>>>>>>>> If I understood you right, gemini-blueprint
is the replacement
>>>> of
>>>>>>>>>>>> spring-dm. In this case, there is no need
that both live
>>>> together.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> I'm
>>>>>>>>>>>> right?
>>>>>>>>>>>> In this case, I don't understand what the
issue is?
>>>>>>>>>>>> 
>>>>>>>>>>>> Best,
>>>>>>>>>>>> Christian
>>>>>>>>>>>> 
>>>>>>>>>>>> On Wed, Oct 10, 2012 at 12:53 PM, Benjamin
Graf
>>>>>>>>>>>> <Benjamin.Graf@gmx.net (mailto:Benjamin.Graf@gmx.net)>wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi everybody,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I tried to implement a new camel component
for
>>>> gemini-blueprint.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> It
>>>>>>>>>>>> seems
>>>>>>>>>>>>> that both components spring-osgi and
gemini-blueprint can not
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> live
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> both
>>>>>>>>>>>>> together in camel. Since camel-spring
needs spring-osgi if
>>>> used
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> in an
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> osgi
>>>>>>>>>>>>> environment. A replacement should really
be considered.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Any suggestions?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Benjamin
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -------- Original-Nachricht --------
>>>>>>>>>>>>>> Datum: Tue, 09 Oct 2012 11:19:36
+0200
>>>>>>>>>>>>>> Von: "Benjamin Graf" <Benjamin.Graf@gmx.net
>>>> (mailto:Benjamin.Graf@gmx.net)
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> (mailto:Benjamin.Graf@gmx.net)>
>>>>>>>>>>>>>> An: dev@camel.apache.org (mailto:dev@camel.apache.org)
>>>>>>>>>>>>>> Betreff: Re: Dependencies of camel-spring
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I give it a try it's two changed
imports and one dependeny
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> change
>>>>>>>>>>>> in pom
>>>>>>>>>>>>>> of camel-spring and everything works
fine:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> import
>>>> org.eclipse.gemini.blueprint.context.BundleContextAware;
>>>>>>>>>>>>>> in
>>>> apache-camel-2.10.0\components\camel-spring\src\main\java\org\apache\camel\osgi\CamelContextFactoryBean.java
>>>> apache-camel-2.10.0\components\camel-spring\src\main\java\org\apache\camel\osgi\CamelNamespaceHandler.java
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> <dependency>
>>>>>>>>>>>>>> <groupId>org.eclipse.gemini.blueprint</groupId>
>>>>>>>>>>>>>> <artifactId>gemini-blueprint-core</artifactId>
>>>>>>>>>>>>>> <version>1.0.2.RELEASE</version>
>>>>>>>>>>>>>> <optional>true</optional>
>>>>>>>>>>>>>> <exclusions>
>>>>>>>>>>>>>> <exclusion>
>>>>>>>>>>>>>> <groupId>org.springframework</groupId>
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> <artifactId>org.springframework.aop</artifactId>
>>>>>>>>>>>>>> </exclusion>
>>>>>>>>>>>>>> <exclusion>
>>>>>>>>>>>>>> <groupId>org.springframework</groupId>
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> <artifactId>org.springframework.beans</artifactId>
>>>>>>>>>>>>>> </exclusion>
>>>>>>>>>>>>>> <exclusion>
>>>>>>>>>>>>>> <groupId>org.springframework</groupId>
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> <artifactId>org.springframework.context</artifactId>
>>>>>>>>>>>>>> </exclusion>
>>>>>>>>>>>>>> <exclusion>
>>>>>>>>>>>>>> <groupId>org.springframework</groupId>
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> <artifactId>org.springframework.core</artifactId>
>>>>>>>>>>>>>> </exclusion>
>>>>>>>>>>>>>> </exclusions>
>>>>>>>>>>>>>> </dependency>
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>> apache-camel-2.10.0\components\camel-spring\pom.xml
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> In my opinion it worth changing it.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> -------- Original-Nachricht --------
>>>>>>>>>>>>>>> Datum: Tue, 9 Oct 2012 11:03:50
+0200
>>>>>>>>>>>>>>> Von: Claus Ibsen <claus.ibsen@gmail.com
>>>> (mailto:claus.ibsen@gmail.com)
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> (mailto:claus.ibsen@gmail.com)>
>>>>>>>>>>>>>>> An: dev@camel.apache.org (mailto:dev@camel.apache.org)
>>>>>>>>>>>>>>> Betreff: Re: Dependencies of
camel-spring
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Tue, Oct 9, 2012 at 10:08
AM, Benjamin Graf
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> <Benjamin.Graf@gmx.net (mailto:Benjamin.Graf@gmx.net)>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> does anybody knows why camel-spring
still depends on
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> spring-osgi?
>>>>>>>>>>>>> This
>>>>>>>>>>>>>>> bundle is gemini-blueprint since
2009 and won't be
>>>> developed
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> anymore.
>>>>>>>>>>>>>> This
>>>>>>>>>>>>>>> fact forces to use an old unsupported
bundle if you like
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> camel
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> with
>>>>>>>>>>>>>> spring
>>>>>>>>>>>>>>> and OSGi. :-( I think it should
change whether to create a
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> new
>>>>>>>>>>>>>>> camel-gemini-bluepint component.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> We love contributions, so you
are welcome to work on a
>>>>>>>>>>>>>>> camel-gemini-blueprint component.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> It would be a matter of doing
something similar as we do in
>>>>>>>>>>>>>>> camel-blueprint (aries) which
builds on top of
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> camel-core-osgi
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> and
>>>>>>>>>>>>>>> camel-core-xml.
>>>>>>>>>>>>>>> Would need to implement a namespace
handler, and the
>>>> factory
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> beans,
>>>>>>>>>>>>>>> and i guess some other osgi quirks
to get it integrated.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>> Benjamin
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Claus Ibsen
>>>>>>>>>>>>>>> -----------------
>>>>>>>>>>>>>>> Red Hat, Inc.
>>>>>>>>>>>>>>> FuseSource is now part of Red
Hat
>>>>>>>>>>>>>>> Email: cibsen@redhat.com (mailto:cibsen@redhat.com)
>>>>>>>>>>>>>>> Web: http://fusesource.com
>>>>>>>>>>>>>>> Twitter: davsclaus
>>>>>>>>>>>>>>> Blog: http://davsclaus.com
>>>>>>>>>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Diese Nachricht wurde von meinem Android-Mobiltelefon
mit K-9
>>>> Mail
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> gesendet.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Diese Nachricht wurde von meinem Android-Mobiltelefon
mit K-9
>>>> Mail gesendet.
>>> 
>>> --
>>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>> gesendet.
>> 
>> 
>> 
>> -- 
>> --
>> Scott England-Sullivan
>> Apache Camel Committer
>> Principal Consultant / Sr. Architect | Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> Web:     fusesource.com | redhat.com
>> Blog:     sully6768.blogspot.com
>> Twitter: sully6768

Mime
View raw message