Re: Camel under OSGi without Spring et al.

[Guillaume Nodet]

That's why you should not try to use Spring-DM.  I strongly suggest
switching to blueprint if you plan to deploy routes in OSGi.

The start level won't even fix the spring problems iirc, or at least
not at 100%, mostly because things happen asynchronously, so even
after subsequent startup, spring won't wait for the handlers.  I
suppose your way (using a programmatic wait) might work, but I'm not
sure you can even know when the handler will be ready.
Though I haven't really worked on Spring-DM since a long time.

FWIW, you'll find a detailed post at
http://gnodet.blogspot.com/2010/03/spring-dm-aries-blueprint-and-custom.html

On Fri, Jan 20, 2012 at 16:00, metatech  wrote:
> Hi,
>
> I agree with both of you, start-levels should be avoided.
> However, in this case, the application is defined with a Spring XML using
> Camel routes, so no Java beans are present in the bundle.  The application
> must wait until the Camel namespace is properly registered in the
> camel-spring OSGi activator.  The namespace must be available before the
> Spring XML file is parsed (which constructs the Spring bean definitions).
> This cannot be done with a "osgi:reference" nor a "depends-on" dependency,
> because they happen too late. Start levels are not reliable on the first
> start-up, but they are reliable for the next start-ups. Only a programmatic
> call in an OSGi activator for the application can wait for the camel-spring
> bundle be fully activated, but it is a bit cumbersome.
>
> Regards,
>
> metatech
>
>
> Start-level can't really be trusted, especially if you use blueprint
> for example, which does actually start the blueprint stuff
> asynchronously.
>
> On Thu, Jan 19, 2012 at 15:49, Donald Whytock <dwhytock@> wrote:
>> It may be a matter of personal taste, but I disagree with reliance on
>> start levels.  It should be more reliable to use a BundleListener to
>> track whether a particular bundle has loaded, or a ServiceTracker with
>> the bundle being watched for launching a "here I am" service when
>> initialization is complete.
>>
>> Don
>>
>
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Camel-under-OSGi-without-Spring-et-al-tp4507473p5160645.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 

Guillaume Nodet

Blog: http://gnodet.blogspot.com/

FuseSource, Integration everywhere
http://fusesource.com

Re: Camel under OSGi without Spring et al.

[metatech]

Hi,

I agree with both of you, start-levels should be avoided.
However, in this case, the application is defined with a Spring XML using
Camel routes, so no Java beans are present in the bundle.  The application
must wait until the Camel namespace is properly registered in the
camel-spring OSGi activator.  The namespace must be available before the
Spring XML file is parsed (which constructs the Spring bean definitions).
This cannot be done with a "osgi:reference" nor a "depends-on" dependency,
because they happen too late. Start levels are not reliable on the first
start-up, but they are reliable for the next start-ups. Only a programmatic
call in an OSGi activator for the application can wait for the camel-spring
bundle be fully activated, but it is a bit cumbersome.  

Regards,

metatech


Start-level can't really be trusted, especially if you use blueprint
for example, which does actually start the blueprint stuff
asynchronously.

On Thu, Jan 19, 2012 at 15:49, Donald Whytock <dwhytock@> wrote:
> It may be a matter of personal taste, but I disagree with reliance on
> start levels.  It should be more reliable to use a BundleListener to
> track whether a particular bundle has loaded, or a ServiceTracker with
> the bundle being watched for launching a "here I am" service when
> initialization is complete.
>
> Don
>


--
View this message in context: 
http://camel.465427.n5.nabble.com/Camel-under-OSGi-without-Spring-et-al-tp4507473p5160645.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Camel under OSGi without Spring et al.

[Guillaume Nodet]

Start-level can't really be trusted, especially if you use blueprint
for example, which does actually start the blueprint stuff
asynchronously.

On Thu, Jan 19, 2012 at 15:49, Donald Whytock  wrote:
> It may be a matter of personal taste, but I disagree with reliance on
> start levels.  It should be more reliable to use a BundleListener to
> track whether a particular bundle has loaded, or a ServiceTracker with
> the bundle being watched for launching a "here I am" service when
> initialization is complete.
>
> Don
>
> On Thu, Jan 19, 2012 at 9:39 AM, metatech  wrote:
>> Hi,
>>
>> My previous conclusion was not correct.
>> The Camel initialization happens indeed in the "addingBundle" method, but is
>> called from a SynchronousBundleListener, in the same thread that activates
>> the bundle, and there is only one thread ("FelixStartlevel") that activates
>> all feature bundles, so it should it should fully initialized.
>>
>> However, when the problem happens, the following error is logged :
>> 2012-01-19 09:35:41,655 | INFO  | ExtenderThread-5 |  |
>> CamelNamespaceHandler            | OSGi environment not detected.
>>
>> This can happen if the OSGi activator of the bundle "camel-spring" was not
>> executed before the Camel context is starting.  In SMX 4.4, camel-spring is
>> at start-level 50, and applications are at start-level 60, so the activator
>> is meant to be completed before applications are starting.
>>
>> However, during the first start-up, or when the bundle cache is cleaned up,
>> the bundles delivered as Karaf "features" are installed in parallel with the
>> deployment of applications in the "deploy" directory.  This can explain that
>> the camel-spring (not yet installed at level 50) is executed after some
>> applications are starting.
>>
>> The only solution I can think of is that the bundle cache should be built in
>> a first phase, then the bundle are started in a second phase.
>>
>> Regards,
>>
>> metatech
>>
>>
>>
>>
>> metatech wrote
>>>
>>> However, the Camel initialization is not finished yet, it is performed in
>>> the "addingBundle" method, which registers Camel components, languages,
>>> type converters, ...
>>>
>>
>>
>> --
>> View this message in context: 
>> http://camel.465427.n5.nabble.com/Camel-under-OSGi-without-Spring-et-al-tp4507473p5157820.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 

Guillaume Nodet

Blog: http://gnodet.blogspot.com/

FuseSource, Integration everywhere
http://fusesource.com

Re: Camel under OSGi without Spring et al.

[Donald Whytock]

It may be a matter of personal taste, but I disagree with reliance on
start levels.  It should be more reliable to use a BundleListener to
track whether a particular bundle has loaded, or a ServiceTracker with
the bundle being watched for launching a "here I am" service when
initialization is complete.

Don

On Thu, Jan 19, 2012 at 9:39 AM, metatech  wrote:
> Hi,
>
> My previous conclusion was not correct.
> The Camel initialization happens indeed in the "addingBundle" method, but is
> called from a SynchronousBundleListener, in the same thread that activates
> the bundle, and there is only one thread ("FelixStartlevel") that activates
> all feature bundles, so it should it should fully initialized.
>
> However, when the problem happens, the following error is logged :
> 2012-01-19 09:35:41,655 | INFO  | ExtenderThread-5 |  |
> CamelNamespaceHandler            | OSGi environment not detected.
>
> This can happen if the OSGi activator of the bundle "camel-spring" was not
> executed before the Camel context is starting.  In SMX 4.4, camel-spring is
> at start-level 50, and applications are at start-level 60, so the activator
> is meant to be completed before applications are starting.
>
> However, during the first start-up, or when the bundle cache is cleaned up,
> the bundles delivered as Karaf "features" are installed in parallel with the
> deployment of applications in the "deploy" directory.  This can explain that
> the camel-spring (not yet installed at level 50) is executed after some
> applications are starting.
>
> The only solution I can think of is that the bundle cache should be built in
> a first phase, then the bundle are started in a second phase.
>
> Regards,
>
> metatech
>
>
>
>
> metatech wrote
>>
>> However, the Camel initialization is not finished yet, it is performed in
>> the "addingBundle" method, which registers Camel components, languages,
>> type converters, ...
>>
>
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Camel-under-OSGi-without-Spring-et-al-tp4507473p5157820.html
> Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Camel under OSGi without Spring et al.

[metatech]

Hi,

My previous conclusion was not correct.
The Camel initialization happens indeed in the "addingBundle" method, but is
called from a SynchronousBundleListener, in the same thread that activates
the bundle, and there is only one thread ("FelixStartlevel") that activates
all feature bundles, so it should it should fully initialized.

However, when the problem happens, the following error is logged : 
2012-01-19 09:35:41,655 | INFO  | ExtenderThread-5 |  |
CamelNamespaceHandler| OSGi environment not detected.

This can happen if the OSGi activator of the bundle "camel-spring" was not
executed before the Camel context is starting.  In SMX 4.4, camel-spring is
at start-level 50, and applications are at start-level 60, so the activator
is meant to be completed before applications are starting.

However, during the first start-up, or when the bundle cache is cleaned up,
the bundles delivered as Karaf "features" are installed in parallel with the
deployment of applications in the "deploy" directory.  This can explain that
the camel-spring (not yet installed at level 50) is executed after some
applications are starting.

The only solution I can think of is that the bundle cache should be built in
a first phase, then the bundle are started in a second phase.

Regards,

metatech




metatech wrote
> 
> However, the Camel initialization is not finished yet, it is performed in
> the "addingBundle" method, which registers Camel components, languages,
> type converters, ...
> 


--
View this message in context: 
http://camel.465427.n5.nabble.com/Camel-under-OSGi-without-Spring-et-al-tp4507473p5157820.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Camel under OSGi without Spring et al.

[metatech]

Hi,

I have more information about the problem.
The method "start" of the class "org.apache.camel.impl.osgi.Activator"
terminates immediately, after registering a callback ("BundleTracker") to be
notified when the bundle enters the "Active" state in the OSGi point of
view.
However, the Camel initialization is not finished yet, it is performed in
the "addingBundle" method, which registers Camel components, languages, type
converters, ...
It explains the cause of the race condition.

Remark : my application bundle is configured at start-level 60 and all Camel
bundles are configured at start-level 50, therefore it shows that the fix
below might reduce the window of race condition, but will not guarantee that
it does not happen anymore :
https://issues.apache.org/jira/browse/SMX4-744

Should I create a bug in JIRA ?

Regards,

metatech

--
View this message in context: 
http://camel.465427.n5.nabble.com/Camel-under-OSGi-without-Spring-et-al-tp4507473p5041913.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Camel under OSGi without Spring et al.

[metatech]

tTypeConverter.doStart(DefaultTypeConverter.java:41)[90:org.apache.camel.camel-core:2.6.0]
at
org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:65)[90:org.apache.camel.camel-core:2.6.0]
at
org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:52)[90:org.apache.camel.camel-core:2.6.0]
at
org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:52)[90:org.apache.camel.camel-core:2.6.0]
at
org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:1593)[90:org.apache.camel.camel-core:2.6.0]
at
org.apache.camel.impl.DefaultCamelContext.addService(DefaultCamelContext.java:884)[90:org.apache.camel.camel-core:2.6.0]
at
org.apache.camel.impl.DefaultCamelContext.getTypeConverter(DefaultCamelContext.java:969)[90:org.apache.camel.camel-core:2.6.0]
... 20 more


--
View this message in context: 
http://camel.465427.n5.nabble.com/Camel-under-OSGi-without-Spring-et-al-tp4507473p5038265.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Camel under OSGi without Spring et al.

[Claus Ibsen]

On Tue, Jun 28, 2011 at 4:29 PM, Donald Whytock  wrote:
> Sorry, forgot about that.  I'd written a dummy class to replace the
> Spring dependency in camel-mail, since, out of the twenty-some methods
> in the Spring class, camel-mail uses maybe two.
>

Yeah camel-mail only uses spring for *sending* emails.

I would like to remove that dependency, but frankly the Java Mail API
is cumbersome to work with. And I heard about troubles with sending
mails to outlook, notes, web mails etc looks different. So you may
have to do some hacks to get it working among those. And I guess the
spring guys most likely have done that already.



> There should maybe be a JIRA to make this a soft dependency like JMX's
> dependency  appears to be.
>
> On Tue, Jun 28, 2011 at 9:37 AM, Michael Furtak  wrote:
>> I looked into continuing my testing with camel-mail, but stopped short 
>> because it also has a dependency on Spring (JavaMailSender).
>>
>> However, I did test with camel-xmpp to great success. Besides bringing in 
>> the correct libraries, the only code change was to ensure that my starter 
>> also bound a ComponentResolver (component=xmpp) before activating.
>>
>>
>> One other Spring dependency worth noting is that JMX management seems to 
>> depend on it. From my log:
>>
>> [27 Jun 2011 12:20:12]  INFO  [Component Resolve Thread] 
>> OsgiDefaultCamelContext - JMX enabled. Using ManagedManagementStrategy.
>> [27 Jun 2011 12:20:12]  TRACE [Component Resolve Thread] ServiceHelper - 
>> Starting service: 
>> org.apache.camel.management.ManagedManagementStrategy@1865b28
>> [27 Jun 2011 12:20:12]  WARN  [Component Resolve Thread] 
>> OsgiDefaultCamelContext - Cannot find needed classes for JMX lifecycle 
>> strategy. Needed class is in spring-context.jar using Spring 2.5 or newer 
>> (spring-jmx.jar using Spring 2.0.x). NoClassDefFoundError: 
>> org/springframework/jmx/export/metadata/JmxAttributeSource
>> [27 Jun 2011 12:20:12]  WARN  [Component Resolve Thread] 
>> OsgiDefaultCamelContext - Cannot use JMX. Fallback to using 
>> DefaultManagementStrategy (non JMX).
>>
>>
>> Thanks to everyone who helped me work this out. I'm feeling a bit more 
>> confident that I can use Camel in my project now.
>>
>> Best,
>> -Mike Furtak
>>
>>
>>
>>
>>
>>
>>
>> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. 
>> IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
>> DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
>> use of this message for any purpose is strictly prohibited. If you have 
>> received this communication in error, please delete the message and notify 
>> the sender so that we may correct our records.
>>
>> -Original Message-
>>
>>
>>
>> From: Donald Whytock [mailto:dwhyt...@gmail.com]
>> Sent: Monday, June 27, 2011 4:42 PM
>> To: users@camel.apache.org
>> Subject: Re: Camel under OSGi without Spring et al.
>>
>> Seems reasonable, since presumably OsgiPackageScanClassResolver is
>> more made to be used in an OSGI environment than the
>> DefaultPackageScanClassResolver.  This might also solve a problem I
>> was having, where OsgiDefaultCamelContext.getComponentNames() was
>> coming up empty.
>>
>> Can you test with a non-core component as well, such as mail?
>>
>> On Mon, Jun 27, 2011 at 4:21 PM, Michael Furtak  wrote:
>>> Ok. I seem to have found a resolution. Now the question is whether or not 
>>> it is appropriate. :)
>>>
>>> Since we seemed to agree that classes are not being found by their 
>>> annotations, I tried to backtrace how that was being resolved. Where I 
>>> wound up was in 
>>> org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:166)
>>>
>>> There, it seems to be setting up the DefaultTypeConverter which will be 
>>> used as the delegate. It sets it up to use a 
>>> DefaultPackageScanClassResolver, which seems to be failing to find 
>>> anything. If I change:
>>>
>>> protected DefaultTypeConverter createRegistry() {
>>>  // base the osgi type converter on the default type converter
>>>  DefaultTypeConverter answer = new DefaultTypeConverter(new 
>>> DefaultPackageScanClassResolver() {
>>>    @Override
>>>    public Set getClassLoaders() {
>>>      // we don't need any classloaders as we use osgi service tracker 
>>> instead
>>>      return Collections.emptySet();
>>>  

Re: Camel under OSGi without Spring et al.

[Donald Whytock]

Sorry, forgot about that.  I'd written a dummy class to replace the
Spring dependency in camel-mail, since, out of the twenty-some methods
in the Spring class, camel-mail uses maybe two.

There should maybe be a JIRA to make this a soft dependency like JMX's
dependency  appears to be.

On Tue, Jun 28, 2011 at 9:37 AM, Michael Furtak  wrote:
> I looked into continuing my testing with camel-mail, but stopped short 
> because it also has a dependency on Spring (JavaMailSender).
>
> However, I did test with camel-xmpp to great success. Besides bringing in the 
> correct libraries, the only code change was to ensure that my starter also 
> bound a ComponentResolver (component=xmpp) before activating.
>
>
> One other Spring dependency worth noting is that JMX management seems to 
> depend on it. From my log:
>
> [27 Jun 2011 12:20:12]  INFO  [Component Resolve Thread] 
> OsgiDefaultCamelContext - JMX enabled. Using ManagedManagementStrategy.
> [27 Jun 2011 12:20:12]  TRACE [Component Resolve Thread] ServiceHelper - 
> Starting service: 
> org.apache.camel.management.ManagedManagementStrategy@1865b28
> [27 Jun 2011 12:20:12]  WARN  [Component Resolve Thread] 
> OsgiDefaultCamelContext - Cannot find needed classes for JMX lifecycle 
> strategy. Needed class is in spring-context.jar using Spring 2.5 or newer 
> (spring-jmx.jar using Spring 2.0.x). NoClassDefFoundError: 
> org/springframework/jmx/export/metadata/JmxAttributeSource
> [27 Jun 2011 12:20:12]  WARN  [Component Resolve Thread] 
> OsgiDefaultCamelContext - Cannot use JMX. Fallback to using 
> DefaultManagementStrategy (non JMX).
>
>
> Thanks to everyone who helped me work this out. I'm feeling a bit more 
> confident that I can use Camel in my project now.
>
> Best,
> -Mike Furtak
>
>
>
>
>
>
>
> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. 
> IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
> DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
> use of this message for any purpose is strictly prohibited. If you have 
> received this communication in error, please delete the message and notify 
> the sender so that we may correct our records.
>
> -Original Message-----
>
>
>
> From: Donald Whytock [mailto:dwhyt...@gmail.com]
> Sent: Monday, June 27, 2011 4:42 PM
> To: users@camel.apache.org
> Subject: Re: Camel under OSGi without Spring et al.
>
> Seems reasonable, since presumably OsgiPackageScanClassResolver is
> more made to be used in an OSGI environment than the
> DefaultPackageScanClassResolver.  This might also solve a problem I
> was having, where OsgiDefaultCamelContext.getComponentNames() was
> coming up empty.
>
> Can you test with a non-core component as well, such as mail?
>
> On Mon, Jun 27, 2011 at 4:21 PM, Michael Furtak  wrote:
>> Ok. I seem to have found a resolution. Now the question is whether or not it 
>> is appropriate. :)
>>
>> Since we seemed to agree that classes are not being found by their 
>> annotations, I tried to backtrace how that was being resolved. Where I wound 
>> up was in 
>> org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:166)
>>
>> There, it seems to be setting up the DefaultTypeConverter which will be used 
>> as the delegate. It sets it up to use a DefaultPackageScanClassResolver, 
>> which seems to be failing to find anything. If I change:
>>
>> protected DefaultTypeConverter createRegistry() {
>>  // base the osgi type converter on the default type converter
>>  DefaultTypeConverter answer = new DefaultTypeConverter(new 
>> DefaultPackageScanClassResolver() {
>>    @Override
>>    public Set getClassLoaders() {
>>      // we don't need any classloaders as we use osgi service tracker instead
>>      return Collections.emptySet();
>>    }
>>  }, injector, factoryFinder);
>> // ...
>>
>> to:
>>
>> protected DefaultTypeConverter createRegistry() {
>>  // base the osgi type converter on the default type converter
>>  PackageScanClassResolver resolver = new 
>> OsgiPackageScanClassResolver(bundleContext);
>>  DefaultTypeConverter answer = new DefaultTypeConverter(resolver, injector, 
>> factoryFinder);
>>
>>
>> then I get a successful startup and a working test case:
>>
>> from("file:data/inbox").to("file:data/outbox");
>>
>>
>> Hurrah! So, is this a reasonable fix? Does the code I replaced in 
>> OsgiTypeConverter make sense as written?
>>
>> Thanks to all who've helped so far.
>>
>&

RE: Camel under OSGi without Spring et al.

[Michael Furtak]

I looked into continuing my testing with camel-mail, but stopped short because 
it also has a dependency on Spring (JavaMailSender).

However, I did test with camel-xmpp to great success. Besides bringing in the 
correct libraries, the only code change was to ensure that my starter also 
bound a ComponentResolver (component=xmpp) before activating.


One other Spring dependency worth noting is that JMX management seems to depend 
on it. From my log:

[27 Jun 2011 12:20:12]  INFO  [Component Resolve Thread] 
OsgiDefaultCamelContext - JMX enabled. Using ManagedManagementStrategy.
[27 Jun 2011 12:20:12]  TRACE [Component Resolve Thread] ServiceHelper - 
Starting service: org.apache.camel.management.ManagedManagementStrategy@1865b28
[27 Jun 2011 12:20:12]  WARN  [Component Resolve Thread] 
OsgiDefaultCamelContext - Cannot find needed classes for JMX lifecycle 
strategy. Needed class is in spring-context.jar using Spring 2.5 or newer 
(spring-jmx.jar using Spring 2.0.x). NoClassDefFoundError: 
org/springframework/jmx/export/metadata/JmxAttributeSource
[27 Jun 2011 12:20:12]  WARN  [Component Resolve Thread] 
OsgiDefaultCamelContext - Cannot use JMX. Fallback to using 
DefaultManagementStrategy (non JMX).


Thanks to everyone who helped me work this out. I'm feeling a bit more 
confident that I can use Camel in my project now.

Best,
-Mike Furtak







THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT 
MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.

-Original Message-



From: Donald Whytock [mailto:dwhyt...@gmail.com]
Sent: Monday, June 27, 2011 4:42 PM
To: users@camel.apache.org
Subject: Re: Camel under OSGi without Spring et al.

Seems reasonable, since presumably OsgiPackageScanClassResolver is
more made to be used in an OSGI environment than the
DefaultPackageScanClassResolver.  This might also solve a problem I
was having, where OsgiDefaultCamelContext.getComponentNames() was
coming up empty.

Can you test with a non-core component as well, such as mail?

On Mon, Jun 27, 2011 at 4:21 PM, Michael Furtak  wrote:
> Ok. I seem to have found a resolution. Now the question is whether or not it 
> is appropriate. :)
>
> Since we seemed to agree that classes are not being found by their 
> annotations, I tried to backtrace how that was being resolved. Where I wound 
> up was in 
> org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:166)
>
> There, it seems to be setting up the DefaultTypeConverter which will be used 
> as the delegate. It sets it up to use a DefaultPackageScanClassResolver, 
> which seems to be failing to find anything. If I change:
>
> protected DefaultTypeConverter createRegistry() {
>  // base the osgi type converter on the default type converter
>  DefaultTypeConverter answer = new DefaultTypeConverter(new 
> DefaultPackageScanClassResolver() {
>@Override
>public Set getClassLoaders() {
>  // we don't need any classloaders as we use osgi service tracker instead
>  return Collections.emptySet();
>}
>  }, injector, factoryFinder);
> // ...
>
> to:
>
> protected DefaultTypeConverter createRegistry() {
>  // base the osgi type converter on the default type converter
>  PackageScanClassResolver resolver = new 
> OsgiPackageScanClassResolver(bundleContext);
>  DefaultTypeConverter answer = new DefaultTypeConverter(resolver, injector, 
> factoryFinder);
>
>
> then I get a successful startup and a working test case:
>
> from("file:data/inbox").to("file:data/outbox");
>
>
> Hurrah! So, is this a reasonable fix? Does the code I replaced in 
> OsgiTypeConverter make sense as written?
>
> Thanks to all who've helped so far.
>
> -Mike
>
>
>
>
>
>
>
> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. 
> IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
> DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
> use of this message for any purpose is strictly prohibited. If you have 
> received this communication in error, please delete the message and notify 
> the sender so that we may correct our records.
>
> -Original Message-
>
>
>
> From: Donald Whytock [mailto:dwhyt...@gmail.com]
> Sent: Monday, June 27, 2011 1:56 PM
> To: users@camel.apache.org
> Subject: Re: Camel under OSGi without Spring et al.
>
> No specific thoughts, no.  It's fairly clear you're waiting for
> TypeConverterLo

Re: Camel under OSGi without Spring et al.

[Christian Schneider]

Either that or the OsgiCamelContext should be in an exported package.

Christian


Am 27.06.2011 22:51, schrieb Donald Whytock:

On Mon, Jun 27, 2011 at 4:38 PM, Christian Schneider
  wrote:

Have you tried using the org.apache.camel.osgi.CamelContextFactory?
It is located in the camel-spring module. Honestly no idea why as it does
not have to do with spring.

cf = new CamelContextFactory();
cf.setBundleContext(context);
cf.createContext();

Can/should it be moved to camel-core-osgi?  Since this whole thread is
about using OSGi without Spring?

Don



--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: Camel under OSGi without Spring et al.

[Donald Whytock]

On Mon, Jun 27, 2011 at 4:38 PM, Christian Schneider
 wrote:
> Have you tried using the org.apache.camel.osgi.CamelContextFactory?
> It is located in the camel-spring module. Honestly no idea why as it does
> not have to do with spring.
>
> cf = new CamelContextFactory();
> cf.setBundleContext(context);
> cf.createContext();

Can/should it be moved to camel-core-osgi?  Since this whole thread is
about using OSGi without Spring?

Don

Re: Camel under OSGi without Spring et al.

[Donald Whytock]

Seems reasonable, since presumably OsgiPackageScanClassResolver is
more made to be used in an OSGI environment than the
DefaultPackageScanClassResolver.  This might also solve a problem I
was having, where OsgiDefaultCamelContext.getComponentNames() was
coming up empty.

Can you test with a non-core component as well, such as mail?

On Mon, Jun 27, 2011 at 4:21 PM, Michael Furtak  wrote:
> Ok. I seem to have found a resolution. Now the question is whether or not it 
> is appropriate. :)
>
> Since we seemed to agree that classes are not being found by their 
> annotations, I tried to backtrace how that was being resolved. Where I wound 
> up was in 
> org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:166)
>
> There, it seems to be setting up the DefaultTypeConverter which will be used 
> as the delegate. It sets it up to use a DefaultPackageScanClassResolver, 
> which seems to be failing to find anything. If I change:
>
> protected DefaultTypeConverter createRegistry() {
>  // base the osgi type converter on the default type converter
>  DefaultTypeConverter answer = new DefaultTypeConverter(new 
> DefaultPackageScanClassResolver() {
>    @Override
>    public Set getClassLoaders() {
>      // we don't need any classloaders as we use osgi service tracker instead
>      return Collections.emptySet();
>    }
>  }, injector, factoryFinder);
> // ...
>
> to:
>
> protected DefaultTypeConverter createRegistry() {
>  // base the osgi type converter on the default type converter
>  PackageScanClassResolver resolver = new 
> OsgiPackageScanClassResolver(bundleContext);
>  DefaultTypeConverter answer = new DefaultTypeConverter(resolver, injector, 
> factoryFinder);
>
>
> then I get a successful startup and a working test case:
>
> from("file:data/inbox").to("file:data/outbox");
>
>
> Hurrah! So, is this a reasonable fix? Does the code I replaced in 
> OsgiTypeConverter make sense as written?
>
> Thanks to all who've helped so far.
>
> -Mike
>
>
>
>
>
>
>
> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. 
> IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
> DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
> use of this message for any purpose is strictly prohibited. If you have 
> received this communication in error, please delete the message and notify 
> the sender so that we may correct our records.
>
> -Original Message-
>
>
>
> From: Donald Whytock [mailto:dwhyt...@gmail.com]
> Sent: Monday, June 27, 2011 1:56 PM
> To: users@camel.apache.org
> Subject: Re: Camel under OSGi without Spring et al.
>
> No specific thoughts, no.  It's fairly clear you're waiting for
> TypeConverterLoader to be registered before you're trying to start the
> CamelContext, and (if this is all the code you have loaded) you're not
> trying to access a file component.  Honestly, I think it should work,
> but again I'm not familiar with Declarative Services.
>
> My startup log file has some lines yours doesn't...
>
> org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
> Found 13 @Converter classes to load
> org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
> Loading converter class:
> org.apache.camel.component.file.GenericFileConverter
> org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
> Loading converter class: org.apache.camel.component.bean.BeanConverter
> org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
> Loading converter class: org.apache.camel.converter.CamelConverter
> org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
> Loading converter class:
> org.apache.camel.converter.CollectionConverter
> org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
> Loading converter class: org.apache.camel.converter.IOConverter
> org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
> Loading converter class: org.apache.camel.converter.NIOConverter
> org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
> Loading converter class: org.apache.camel.converter.ObjectConverter
> org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
> Loading converter class:
> org.apache.camel.converter.TimePatternConverter
> org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
> Loading converter class: org.apache.camel.converter.jaxp.DomConverter
> org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
> Loading converter class: org.apache.camel.converter.jaxp.StaxConverter
> org.apache.camel.camel

Re: Camel under OSGi without Spring et al.

[Christian Schneider]

Have you tried using the org.apache.camel.osgi.CamelContextFactory?
It is located in the camel-spring module. Honestly no idea why as it 
does not have to do with spring.


cf = new CamelContextFactory();
cf.setBundleContext(context);
cf.createContext();

You can do this from you bundle Activator. This creates a CamelContext 
suitable for Osgi that finds all converters and components.
The nice thing is that you do not even have to import the packages for 
the components.


Christian

Am 27.06.2011 22:21, schrieb Michael Furtak:

Ok. I seem to have found a resolution. Now the question is whether or not it is 
appropriate. :)

Since we seemed to agree that classes are not being found by their annotations, 
I tried to backtrace how that was being resolved. Where I wound up was in 
org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:166)

There, it seems to be setting up the DefaultTypeConverter which will be used as 
the delegate. It sets it up to use a DefaultPackageScanClassResolver, which 
seems to be failing to find anything. If I change:

protected DefaultTypeConverter createRegistry() {
   // base the osgi type converter on the default type converter
   DefaultTypeConverter answer = new DefaultTypeConverter(new 
DefaultPackageScanClassResolver() {
 @Override
 public Set  getClassLoaders() {
   // we don't need any classloaders as we use osgi service tracker instead
   return Collections.emptySet();
 }
   }, injector, factoryFinder);
// ...

to:

protected DefaultTypeConverter createRegistry() {
   // base the osgi type converter on the default type converter
   PackageScanClassResolver resolver = new 
OsgiPackageScanClassResolver(bundleContext);
   DefaultTypeConverter answer = new DefaultTypeConverter(resolver, injector, 
factoryFinder);


then I get a successful startup and a working test case:

from("file:data/inbox").to("file:data/outbox");


Hurrah! So, is this a reasonable fix? Does the code I replaced in 
OsgiTypeConverter make sense as written?

Thanks to all who've helped so far.

-Mike




--
--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

RE: Camel under OSGi without Spring et al.

[Michael Furtak]

Ok. I seem to have found a resolution. Now the question is whether or not it is 
appropriate. :)

Since we seemed to agree that classes are not being found by their annotations, 
I tried to backtrace how that was being resolved. Where I wound up was in 
org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:166)

There, it seems to be setting up the DefaultTypeConverter which will be used as 
the delegate. It sets it up to use a DefaultPackageScanClassResolver, which 
seems to be failing to find anything. If I change:

protected DefaultTypeConverter createRegistry() {
  // base the osgi type converter on the default type converter
  DefaultTypeConverter answer = new DefaultTypeConverter(new 
DefaultPackageScanClassResolver() {
@Override
public Set getClassLoaders() {
  // we don't need any classloaders as we use osgi service tracker instead
  return Collections.emptySet();
}
  }, injector, factoryFinder);
// ...

to:

protected DefaultTypeConverter createRegistry() {
  // base the osgi type converter on the default type converter
  PackageScanClassResolver resolver = new 
OsgiPackageScanClassResolver(bundleContext);
  DefaultTypeConverter answer = new DefaultTypeConverter(resolver, injector, 
factoryFinder);


then I get a successful startup and a working test case:

from("file:data/inbox").to("file:data/outbox");


Hurrah! So, is this a reasonable fix? Does the code I replaced in 
OsgiTypeConverter make sense as written?

Thanks to all who've helped so far.

-Mike







THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT 
MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.

-Original Message-



From: Donald Whytock [mailto:dwhyt...@gmail.com]
Sent: Monday, June 27, 2011 1:56 PM
To: users@camel.apache.org
Subject: Re: Camel under OSGi without Spring et al.

No specific thoughts, no.  It's fairly clear you're waiting for
TypeConverterLoader to be registered before you're trying to start the
CamelContext, and (if this is all the code you have loaded) you're not
trying to access a file component.  Honestly, I think it should work,
but again I'm not familiar with Declarative Services.

My startup log file has some lines yours doesn't...

org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Found 13 @Converter classes to load
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class:
org.apache.camel.component.file.GenericFileConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class: org.apache.camel.component.bean.BeanConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class: org.apache.camel.converter.CamelConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class:
org.apache.camel.converter.CollectionConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class: org.apache.camel.converter.IOConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class: org.apache.camel.converter.NIOConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class: org.apache.camel.converter.ObjectConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class:
org.apache.camel.converter.TimePatternConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class: org.apache.camel.converter.jaxp.DomConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class: org.apache.camel.converter.jaxp.StaxConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class:
org.apache.camel.converter.jaxp.StreamSourceConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class: org.apache.camel.converter.jaxp.XmlConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class:
org.apache.camel.converter.stream.StreamCacheConverter

which might correspond to the "Searching for annotations" line in your
log.  Random thought...are annotations enabled in your JVM?

I'm sending the rest of the pieces of my bundle (under separate cover,
as the list apparently eats attachments; available to others on
request).  If that doesn't work for you either, my guess is something
in your Camel config.

Don

On Mon, Jun 27, 2011 at 12:26 PM, Michael Furtak  wrote:
> Hi Don,
>
> Tha

Re: Camel under OSGi without Spring et al.

[Donald Whytock]

No specific thoughts, no.  It's fairly clear you're waiting for
TypeConverterLoader to be registered before you're trying to start the
CamelContext, and (if this is all the code you have loaded) you're not
trying to access a file component.  Honestly, I think it should work,
but again I'm not familiar with Declarative Services.

My startup log file has some lines yours doesn't...

org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Found 13 @Converter classes to load
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class:
org.apache.camel.component.file.GenericFileConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class: org.apache.camel.component.bean.BeanConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class: org.apache.camel.converter.CamelConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class:
org.apache.camel.converter.CollectionConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class: org.apache.camel.converter.IOConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class: org.apache.camel.converter.NIOConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class: org.apache.camel.converter.ObjectConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class:
org.apache.camel.converter.TimePatternConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class: org.apache.camel.converter.jaxp.DomConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class: org.apache.camel.converter.jaxp.StaxConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class:
org.apache.camel.converter.jaxp.StreamSourceConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class: org.apache.camel.converter.jaxp.XmlConverter
org.apache.camel.camel-core[org.apache.camel.impl.osgi.Activator] :
Loading converter class:
org.apache.camel.converter.stream.StreamCacheConverter

which might correspond to the "Searching for annotations" line in your
log.  Random thought...are annotations enabled in your JVM?

I'm sending the rest of the pieces of my bundle (under separate cover,
as the list apparently eats attachments; available to others on
request).  If that doesn't work for you either, my guess is something
in your Camel config.

Don

On Mon, Jun 27, 2011 at 12:26 PM, Michael Furtak  wrote:
> Hi Don,
>
> Thanks for your continued help. I've had my efforts diverted elsewhere for a 
> bit, but I'm back to trying to explore this again today.
>
> Following this message: 
> http://camel.465427.n5.nabble.com/Camel-under-OSGi-without-Spring-et-al-tp4507473p4511826.html
>
> I've modified my test environment slightly. I've added the 
> TypeConverterLoader to the list of services that my CamelStarter requires 
> before it activates. That means that it now binds a ComponentResolver with 
> (component=file) and a TypeConverterLoader before the activate method is 
> invoked. That is also visible in the log. However, the call to 
> camelContext.start() still produces an exception.
>
>
>
>
> 
> http://www.osgi.org/xmlns/scr/v1.1.0"; 
> name="com.cra.camelsandbox.CamelStarter">
>   
>    interface="org.apache.camel.spi.ComponentResolver" name="ComponentResolver" 
> policy="dynamic" target="(component=file)" unbind="unbindComponentResolver"/>
>    interface="org.apache.camel.spi.TypeConverterLoader" 
> name="TypeConverterLoader" policy="dynamic" 
> unbind="unbindTypeConverterLoader"/>
> 
>
>
>
>
> public class CamelStarter
> {
>  private static final transient Logger LOG = 
> LoggerFactory.getLogger(CamelStarter.class);
>
>  protected void activate(ComponentContext context)
>  {
>    try
>    {
>      LOG.trace("activating");
>      CamelContext camelContext = new 
> OsgiDefaultCamelContext(context.getBundleContext());
>      camelContext.start();
>    }
>    catch (Throwable t)
>    {
>      t.printStackTrace();
>    }
>  }
>
>  protected void deactivate(ComponentContext context)
>  {
>    LOG.trace("deactivating");
>  }
>
>  protected void bindComponentResolver(ComponentResolver cr)
>  {
>    LOG.trace("Binding ComponentResolver");
>    // Ignored, since the ComponentResolver is not directly used
>  }
>
>  protected void 

RE: Camel under OSGi without Spring et al.

[Michael Furtak]

Hi Don,

Thanks for your continued help. I've had my efforts diverted elsewhere for a 
bit, but I'm back to trying to explore this again today.

Following this message: 
http://camel.465427.n5.nabble.com/Camel-under-OSGi-without-Spring-et-al-tp4507473p4511826.html

I've modified my test environment slightly. I've added the TypeConverterLoader 
to the list of services that my CamelStarter requires before it activates. That 
means that it now binds a ComponentResolver with (component=file) and a 
TypeConverterLoader before the activate method is invoked. That is also visible 
in the log. However, the call to camelContext.start() still produces an 
exception.





http://www.osgi.org/xmlns/scr/v1.1.0"; 
name="com.cra.camelsandbox.CamelStarter">
   
   
   





public class CamelStarter
{
  private static final transient Logger LOG = 
LoggerFactory.getLogger(CamelStarter.class);

  protected void activate(ComponentContext context)
  {
try
{
  LOG.trace("activating");
  CamelContext camelContext = new 
OsgiDefaultCamelContext(context.getBundleContext());
  camelContext.start();
}
catch (Throwable t)
{
  t.printStackTrace();
}
  }

  protected void deactivate(ComponentContext context)
  {
LOG.trace("deactivating");
  }

  protected void bindComponentResolver(ComponentResolver cr)
  {
LOG.trace("Binding ComponentResolver");
// Ignored, since the ComponentResolver is not directly used
  }

  protected void unbindComponentResolver(ComponentResolver cr)
  {
LOG.trace("Unbinding ComponentResolver");
// Ignored, since the ComponentResolver is not directly used
  }

  protected void bindTypeConverterLoader(TypeConverterLoader tcl)
  {
LOG.trace("Binding TypeConverterLoader");
// Ignored, since the ComponentResolver is not directly used
  }

  protected void unbindTypeConverterLoader(TypeConverterLoader tcl)
  {
LOG.trace("Unbinding TypeConverterLoader");
// Ignored, since the ComponentResolver is not directly used
  }
}



I've also tweaked my logging settings to capture Camel's output, in the hope 
that it provides some more context:





[27 Jun 2011 12:20:11]  INFO  [Start Level Event Dispatcher] Activator - Camel 
activator starting
[27 Jun 2011 12:20:11]  DEBUG [Start Level Event Dispatcher] Activator - Bundle 
started: scala-library
[27 Jun 2011 12:20:11]  DEBUG [Start Level Event Dispatcher] Activator - Bundle 
started: org.eclipse.osgi.services
[27 Jun 2011 12:20:11]  DEBUG [Start Level Event Dispatcher] Activator - Bundle 
started: org.eclipse.equinox.event
[27 Jun 2011 12:20:11]  DEBUG [Start Level Event Dispatcher] Activator - Bundle 
started: org.eclipse.equinox.util
[27 Jun 2011 12:20:11]  DEBUG [Start Level Event Dispatcher] Activator - Bundle 
started: org.eclipse.equinox.ds
[27 Jun 2011 12:20:11]  INFO  [Start Level Event Dispatcher] Activator - Camel 
activator started
[27 Jun 2011 12:20:11]  DEBUG [Start Level Event Dispatcher] Activator - Bundle 
started: org.apache.camel.camel-core
[27 Jun 2011 12:20:11]  DEBUG [Start Level Event Dispatcher] Activator - Found 
entry: META-INF/services/org/apache/camel/component/bean in bundle 
org.apache.camel.camel-core
[27 Jun 2011 12:20:11]  DEBUG [Start Level Event Dispatcher] Activator - Found 
entry: META-INF/services/org/apache/camel/component/browse in bundle 
org.apache.camel.camel-core
[27 Jun 2011 12:20:11]  DEBUG [Start Level Event Dispatcher] Activator - Found 
entry: META-INF/services/org/apache/camel/component/class in bundle 
org.apache.camel.camel-core
[27 Jun 2011 12:20:11]  DEBUG [Start Level Event Dispatcher] Activator - Found 
entry: META-INF/services/org/apache/camel/component/dataset in bundle 
org.apache.camel.camel-core
[27 Jun 2011 12:20:11]  DEBUG [Start Level Event Dispatcher] Activator - Found 
entry: META-INF/services/org/apache/camel/component/direct in bundle 
org.apache.camel.camel-core
[27 Jun 2011 12:20:11]  DEBUG [Start Level Event Dispatcher] Activator - Found 
entry: META-INF/services/org/apache/camel/component/file in bundle 
org.apache.camel.camel-core
[27 Jun 2011 12:20:11]  DEBUG [Start Level Event Dispatcher] Activator - Found 
entry: META-INF/services/org/apache/camel/component/language in bundle 
org.apache.camel.camel-core
[27 Jun 2011 12:20:11]  DEBUG [Start Level Event Dispatcher] Activator - Found 
entry: META-INF/services/org/apache/camel/component/log in bundle 
org.apache.camel.camel-core
[27 Jun 2011 12:20:11]  DEBUG [Start Level Event Dispatcher] Activator - Found 
entry: META-INF/services/org/apache/camel/component/mock in bundle 
org.apache.camel.camel-core
[27 Jun 2011 12:20:11]  DEBUG [Start Level Event Dispatcher] Activator - Found 
entry: META-INF/services/org/apache/camel/component/properties in bundle 
org.apache.camel.camel-core
[27 Jun 2011 12:20:11]  DEBUG [Start Level Event Dispatcher] Activator - Found 
entry: M

Re: Camel under OSGi without Spring et al.

[Gert Vanthienen]

or staring OSGiTypeConverter due: 
>> Failed to load type converters because of: Cannot find any type converter 
>> classes from the following packages: [org.apache.camel.component.file, 
>> org.apache.camel.component.bean, org.apache.camel.converter]
>>        at 
>> org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:206)
>>        at 
>> org.apache.camel.core.osgi.OsgiTypeConverter.getDelegate(OsgiTypeConverter.java:164)
>>        at 
>> org.apache.camel.core.osgi.OsgiTypeConverter.addingService(OsgiTypeConverter.java:69)
>>        at 
>> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896)
>>        at 
>> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261)
>>        at 
>> org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184)
>>        at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:339)
>>        at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:273)
>>        at 
>> org.apache.camel.core.osgi.OsgiTypeConverter.doStart(OsgiTypeConverter.java:102)
>>        at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67)
>>        at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54)
>>        at 
>> org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:60)
>>        at 
>> org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:1613)
>>        at 
>> org.apache.camel.impl.DefaultCamelContext.addService(DefaultCamelContext.java:899)
>>        at 
>> org.apache.camel.impl.DefaultCamelContext.getTypeConverter(DefaultCamelContext.java:984)
>>        at 
>> org.apache.camel.impl.DefaultCamelContext.getTypeConverterRegistry(DefaultCamelContext.java:1001)
>>        at 
>> org.apache.camel.impl.DefaultCamelContext.forceLazyInitialization(DefaultCamelContext.java:1940)
>>        at 
>> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1423)
>>        at 
>> org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1336)
>>        at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67)
>>        at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54)
>>        at 
>> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1314)
>>        at com.cra.camelsandbox.CamelStarter.activate(CamelStarter.java:18)
>>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>        at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>        at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>        at java.lang.reflect.Method.invoke(Method.java:597)
>>        at 
>> org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:210)
>>        at 
>> org.eclipse.equinox.internal.ds.model.ServiceComponentProp.activate(ServiceComponentProp.java:139)
>>        at 
>> org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:339)
>>        at 
>> org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:588)
>>        at 
>> org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:196)
>>        at 
>> org.eclipse.equinox.internal.ds.Resolver.buildNewlySatisfied(Resolver.java:441)
>>        at 
>> org.eclipse.equinox.internal.ds.Resolver.enableComponents(Resolver.java:213)
>>        at 
>> org.eclipse.equinox.internal.ds.SCRManager.performWork(SCRManager.java:800)
>>        at 
>> org.eclipse.equinox.internal.ds.SCRManager$QueuedJob.dispatch(SCRManager.java:767)
>>        at org.eclipse.equinox.internal.ds.WorkThread.run(WorkThread.java:89)
>>        at 
>> org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run(Executor.java:70)
>> Caused by: org.apache.camel.TypeConverterLoaderException: Failed to load 
>> type converters because of: Cannot find any type converter classes from the 
>> following packages: [org.apache.camel.component.file, 
>> org.apache.camel.component.bean, org.apache.camel.converter]
>>        at 
>> org.apache.camel.impl.converter.AnnotationTypeConverterLoader.load(AnnotationTypeConverterLoader.java:79)
>>        at 
>> org.apache.camel.impl.converter.BaseTypeConverterRegistry.loadTypeConverters(BaseTypeConverterRegistry.java:395)
>>        at 
>> org.apache.camel.impl.converter.DefaultTypeConverter.doStart(DefaultTypeConverter.java:41)
>

Re: Camel under OSGi without Spring et al.

[Donald Whytock]

3)
>        at 
> org.apache.camel.core.osgi.OsgiTypeConverter.doStart(OsgiTypeConverter.java:102)
>        at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67)
>        at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54)
>        at 
> org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:60)
>        at 
> org.apache.camel.impl.DefaultCamelContext.startServices(DefaultCamelContext.java:1613)
>        at 
> org.apache.camel.impl.DefaultCamelContext.addService(DefaultCamelContext.java:899)
>        at 
> org.apache.camel.impl.DefaultCamelContext.getTypeConverter(DefaultCamelContext.java:984)
>        at 
> org.apache.camel.impl.DefaultCamelContext.getTypeConverterRegistry(DefaultCamelContext.java:1001)
>        at 
> org.apache.camel.impl.DefaultCamelContext.forceLazyInitialization(DefaultCamelContext.java:1940)
>        at 
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1423)
>        at 
> org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1336)
>        at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67)
>        at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54)
>        at 
> org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1314)
>        at com.cra.camelsandbox.CamelStarter.activate(CamelStarter.java:18)
>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>        at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>        at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>        at java.lang.reflect.Method.invoke(Method.java:597)
>        at 
> org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:210)
>        at 
> org.eclipse.equinox.internal.ds.model.ServiceComponentProp.activate(ServiceComponentProp.java:139)
>        at 
> org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:339)
>        at 
> org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:588)
>        at 
> org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:196)
>        at 
> org.eclipse.equinox.internal.ds.Resolver.buildNewlySatisfied(Resolver.java:441)
>        at 
> org.eclipse.equinox.internal.ds.Resolver.enableComponents(Resolver.java:213)
>        at 
> org.eclipse.equinox.internal.ds.SCRManager.performWork(SCRManager.java:800)
>        at 
> org.eclipse.equinox.internal.ds.SCRManager$QueuedJob.dispatch(SCRManager.java:767)
>        at org.eclipse.equinox.internal.ds.WorkThread.run(WorkThread.java:89)
>        at 
> org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run(Executor.java:70)
> Caused by: org.apache.camel.TypeConverterLoaderException: Failed to load type 
> converters because of: Cannot find any type converter classes from the 
> following packages: [org.apache.camel.component.file, 
> org.apache.camel.component.bean, org.apache.camel.converter]
>        at 
> org.apache.camel.impl.converter.AnnotationTypeConverterLoader.load(AnnotationTypeConverterLoader.java:79)
>        at 
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.loadTypeConverters(BaseTypeConverterRegistry.java:395)
>        at 
> org.apache.camel.impl.converter.DefaultTypeConverter.doStart(DefaultTypeConverter.java:41)
>        at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67)
>        at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54)
>        at 
> org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:60)
>        at 
> org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:202)
>        ... 37 more
>
> Slightly off topic, your advice about needing to share the CamelContext 
> object as a singleton (wrt. SEDA, etc.) was received loud and clear. What you 
> see here is me just trying to keep my test cases simple for now.
>
>
> So that's where I am stuck at the moment. I'm sorry not to be working more 
> directly from your sample code, but please correct me if its service 
> management strategy/intent is different from my understanding. Does my 
> current problem make sense? What am I missing?
>
>
> Thanks,
> -Mike
>
>
>
>
>
>
>
>
> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. 
> IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
> DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
> use of this message for any purpose is strictly prohibited. If you have 
> received this communication in error, ple

RE: Camel under OSGi without Spring et al.

[Michael Furtak]

l.ds.InstanceProcess.buildComponents(InstanceProcess.java:196)
at 
org.eclipse.equinox.internal.ds.Resolver.buildNewlySatisfied(Resolver.java:441)
at 
org.eclipse.equinox.internal.ds.Resolver.enableComponents(Resolver.java:213)
at 
org.eclipse.equinox.internal.ds.SCRManager.performWork(SCRManager.java:800)
at 
org.eclipse.equinox.internal.ds.SCRManager$QueuedJob.dispatch(SCRManager.java:767)
at org.eclipse.equinox.internal.ds.WorkThread.run(WorkThread.java:89)
at 
org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run(Executor.java:70)
Caused by: org.apache.camel.TypeConverterLoaderException: Failed to load type 
converters because of: Cannot find any type converter classes from the 
following packages: [org.apache.camel.component.file, 
org.apache.camel.component.bean, org.apache.camel.converter]
at 
org.apache.camel.impl.converter.AnnotationTypeConverterLoader.load(AnnotationTypeConverterLoader.java:79)
at 
org.apache.camel.impl.converter.BaseTypeConverterRegistry.loadTypeConverters(BaseTypeConverterRegistry.java:395)
at 
org.apache.camel.impl.converter.DefaultTypeConverter.doStart(DefaultTypeConverter.java:41)
at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:67)
at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:54)
at 
org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:60)
at 
org.apache.camel.core.osgi.OsgiTypeConverter.createRegistry(OsgiTypeConverter.java:202)
... 37 more

Slightly off topic, your advice about needing to share the CamelContext object 
as a singleton (wrt. SEDA, etc.) was received loud and clear. What you see here 
is me just trying to keep my test cases simple for now.


So that's where I am stuck at the moment. I'm sorry not to be working more 
directly from your sample code, but please correct me if its service management 
strategy/intent is different from my understanding. Does my current problem 
make sense? What am I missing?


Thanks,
-Mike








THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT 
MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.

-Original Message-



From: Donald Whytock [mailto:dwhyt...@gmail.com]
Sent: Monday, June 20, 2011 4:45 PM
To: users@camel.apache.org
Subject: Re: Camel under OSGi without Spring et al.

OsgiCamelTracker.java (attached) is a work in progress.  There's a
reference to ContextUtil; that's the service class that supplies the
CamelContext singleton.

Use it by subclassing it and implementing methods start() and stop().
Call setBundleContext(bundleContext) first, then startTracking().

OsgiCamelTracker.startTracking() accepts no parameters, a single
String, or a Collection.  The strings are the names of
components that you need.  It'll track instances of ComponentResolver,
maintaining a list of what components are available and what
components are still needed.  When all the components you need are
available, it'll call start(); when any of the components cease to be
available, it'll call stop().

If you don't supply component names, it'll react to camel-core itself
becoming active, which is all you need for core components like mock,
bean and file.

Use routeId() in your route definitions.  Use
camelcontext.startRoute() from the OsgiCamelTracker.start(); use
camelcontext.stopRoute() from the OsgiCamelTracker.stop().

Be advised, you'll need to use a singleton CamelContext if you're
using SEDA queues, because SEDA queues are local to a CamelContext
instance.  A route that consumes from a SEDA queue from one
CamelContext instance won't see anything produced to a SEDA queue from
a different CamelContext instance.

For OsgiDefaultCamelContext...

> On Mon, Jun 20, 2011 at 3:31 PM, Michael Furtak  wrote:
>> I did come across mention of this in my troubleshooting exploration. It 
>> seems to be part of a bundle called camel-core-osgi, is that right? I don't 
>> think I have it in my 2.7.2 distribution. Is it something I need to bundle 
>> myself? I also saw mention of it being private to the Spring bundle, which 
>> is what prompted my discussion about not wanting to bring in Spring.

org.apache.camel.core.osgi is in camel-blueprint.jar.  I split it out
into its own .jar so as to not worry about the Blueprint dependencies.
 You'll need to modify the manifest, or make your own.

Don

RE: Camel under OSGi without Spring et al.

[Michael Furtak]

Hi Gert,

I'm clearly only one user (and a seriously new one, at that), but you've 
captured exactly how I would like to use Camel. If I can provide use/test 
cases, or feedback about my limited environment I'd be happy to do so.

Thanks,
-Mike







THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT 
MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.

-Original Message-



From: Gert Vanthienen [mailto:gert.vanthie...@gmail.com]
Sent: Tuesday, June 21, 2011 10:59 AM
To: users@camel.apache.org
Subject: Re: Camel under OSGi without Spring et al.

L.S.,

I think adding support for pure OSGi deployments (no blueprint,
spring, ...) might be an interesting addition to Camel as such.  It's
probably not that useful in the environment we typically have in mind
(ESB, enterprise applications, ...) but for other use cases it may
make perfect sense to be able to have a more lightweight approach
available as well.  Not entirely sure what the current
OsgiCamelTracker is doing, but we could e.g. (just guessing what would
be useful here, so feel free to amend/comment/...) build something
that tracks RouteBuilder instances in the OSGi Service Registry and
then creates CamelContexts to run those, with a service property to
allow configuring the CamelContext instance to add the routes to?

Regards,

Gert Vanthienen

FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/



On Tue, Jun 21, 2011 at 4:38 PM, Donald Whytock  wrote:
> Odd...I can see it there.  I'll send it to you directly.
>
> Don
>
> On Tue, Jun 21, 2011 at 8:01 AM, Michael Furtak  wrote:
>> Hi Don,
>>
>> I wasn't able to find OsgiCamelTracker.java attached to your message.
>>
>> Thanks,
>> -Mike
>>
>>
>>
>>
>>
>>
>>
>> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. 
>> IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
>> DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
>> use of this message for any purpose is strictly prohibited. If you have 
>> received this communication in error, please delete the message and notify 
>> the sender so that we may correct our records.
>>
>> -----Original Message-
>>
>>
>>
>> From: Donald Whytock [mailto:dwhyt...@gmail.com]
>> Sent: Monday, June 20, 2011 4:45 PM
>> To: users@camel.apache.org
>> Subject: Re: Camel under OSGi without Spring et al.
>>
>> OsgiCamelTracker.java (attached) is a work in progress.  There's a
>> reference to ContextUtil; that's the service class that supplies the
>> CamelContext singleton.
>>
>> Use it by subclassing it and implementing methods start() and stop().
>> Call setBundleContext(bundleContext) first, then startTracking().
>>
>> OsgiCamelTracker.startTracking() accepts no parameters, a single
>> String, or a Collection.  The strings are the names of
>> components that you need.  It'll track instances of ComponentResolver,
>> maintaining a list of what components are available and what
>> components are still needed.  When all the components you need are
>> available, it'll call start(); when any of the components cease to be
>> available, it'll call stop().
>>
>> If you don't supply component names, it'll react to camel-core itself
>> becoming active, which is all you need for core components like mock,
>> bean and file.
>>
>> Use routeId() in your route definitions.  Use
>> camelcontext.startRoute() from the OsgiCamelTracker.start(); use
>> camelcontext.stopRoute() from the OsgiCamelTracker.stop().
>>
>> Be advised, you'll need to use a singleton CamelContext if you're
>> using SEDA queues, because SEDA queues are local to a CamelContext
>> instance.  A route that consumes from a SEDA queue from one
>> CamelContext instance won't see anything produced to a SEDA queue from
>> a different CamelContext instance.
>>
>> For OsgiDefaultCamelContext...
>>
>>> On Mon, Jun 20, 2011 at 3:31 PM, Michael Furtak  wrote:
>>>> I did come across mention of this in my troubleshooting exploration. It 
>>>> seems to be part of a bundle called camel-core-osgi, is that right? I 
>>>> don't think I have it in my 2.7.2 distribution. Is it something I need to 
>>>> bundle myself? I also saw mention of it being private to the Spring 
>>>> bundle, which is what prompted my discussion about not wanting to bring in 
>>>> Spring.
>>
>> org.apache.camel.core.osgi is in camel-blueprint.jar.  I split it out
>> into its own .jar so as to not worry about the Blueprint dependencies.
>>  You'll need to modify the manifest, or make your own.
>>
>> Don
>>
>>
>

Re: Camel under OSGi without Spring et al.

[Gert Vanthienen]

L.S.,

I think adding support for pure OSGi deployments (no blueprint,
spring, ...) might be an interesting addition to Camel as such.  It's
probably not that useful in the environment we typically have in mind
(ESB, enterprise applications, ...) but for other use cases it may
make perfect sense to be able to have a more lightweight approach
available as well.  Not entirely sure what the current
OsgiCamelTracker is doing, but we could e.g. (just guessing what would
be useful here, so feel free to amend/comment/...) build something
that tracks RouteBuilder instances in the OSGi Service Registry and
then creates CamelContexts to run those, with a service property to
allow configuring the CamelContext instance to add the routes to?

Regards,

Gert Vanthienen

FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/



On Tue, Jun 21, 2011 at 4:38 PM, Donald Whytock  wrote:
> Odd...I can see it there.  I'll send it to you directly.
>
> Don
>
> On Tue, Jun 21, 2011 at 8:01 AM, Michael Furtak  wrote:
>> Hi Don,
>>
>> I wasn't able to find OsgiCamelTracker.java attached to your message.
>>
>> Thanks,
>> -Mike
>>
>>
>>
>>
>>
>>
>>
>> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. 
>> IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
>> DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
>> use of this message for any purpose is strictly prohibited. If you have 
>> received this communication in error, please delete the message and notify 
>> the sender so that we may correct our records.
>>
>> -Original Message-----
>>
>>
>>
>> From: Donald Whytock [mailto:dwhyt...@gmail.com]
>> Sent: Monday, June 20, 2011 4:45 PM
>> To: users@camel.apache.org
>> Subject: Re: Camel under OSGi without Spring et al.
>>
>> OsgiCamelTracker.java (attached) is a work in progress.  There's a
>> reference to ContextUtil; that's the service class that supplies the
>> CamelContext singleton.
>>
>> Use it by subclassing it and implementing methods start() and stop().
>> Call setBundleContext(bundleContext) first, then startTracking().
>>
>> OsgiCamelTracker.startTracking() accepts no parameters, a single
>> String, or a Collection.  The strings are the names of
>> components that you need.  It'll track instances of ComponentResolver,
>> maintaining a list of what components are available and what
>> components are still needed.  When all the components you need are
>> available, it'll call start(); when any of the components cease to be
>> available, it'll call stop().
>>
>> If you don't supply component names, it'll react to camel-core itself
>> becoming active, which is all you need for core components like mock,
>> bean and file.
>>
>> Use routeId() in your route definitions.  Use
>> camelcontext.startRoute() from the OsgiCamelTracker.start(); use
>> camelcontext.stopRoute() from the OsgiCamelTracker.stop().
>>
>> Be advised, you'll need to use a singleton CamelContext if you're
>> using SEDA queues, because SEDA queues are local to a CamelContext
>> instance.  A route that consumes from a SEDA queue from one
>> CamelContext instance won't see anything produced to a SEDA queue from
>> a different CamelContext instance.
>>
>> For OsgiDefaultCamelContext...
>>
>>> On Mon, Jun 20, 2011 at 3:31 PM, Michael Furtak  wrote:
>>>> I did come across mention of this in my troubleshooting exploration. It 
>>>> seems to be part of a bundle called camel-core-osgi, is that right? I 
>>>> don't think I have it in my 2.7.2 distribution. Is it something I need to 
>>>> bundle myself? I also saw mention of it being private to the Spring 
>>>> bundle, which is what prompted my discussion about not wanting to bring in 
>>>> Spring.
>>
>> org.apache.camel.core.osgi is in camel-blueprint.jar.  I split it out
>> into its own .jar so as to not worry about the Blueprint dependencies.
>>  You'll need to modify the manifest, or make your own.
>>
>> Don
>>
>>
>

Re: Camel under OSGi without Spring et al.

[Norman Maurer]

The ASF mailinglists tend to strip of attachments...

Bye,
Norman

2011/6/21 Donald Whytock :
> Odd...I can see it there.  I'll send it to you directly.
>
> Don
>
> On Tue, Jun 21, 2011 at 8:01 AM, Michael Furtak  wrote:
>> Hi Don,
>>
>> I wasn't able to find OsgiCamelTracker.java attached to your message.
>>
>> Thanks,
>> -Mike
>>
>>
>>
>>
>>
>>
>>
>> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. 
>> IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
>> DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
>> use of this message for any purpose is strictly prohibited. If you have 
>> received this communication in error, please delete the message and notify 
>> the sender so that we may correct our records.
>>
>> -Original Message-
>>
>>
>>
>> From: Donald Whytock [mailto:dwhyt...@gmail.com]
>> Sent: Monday, June 20, 2011 4:45 PM
>> To: users@camel.apache.org
>> Subject: Re: Camel under OSGi without Spring et al.
>>
>> OsgiCamelTracker.java (attached) is a work in progress.  There's a
>> reference to ContextUtil; that's the service class that supplies the
>> CamelContext singleton.
>>
>> Use it by subclassing it and implementing methods start() and stop().
>> Call setBundleContext(bundleContext) first, then startTracking().
>>
>> OsgiCamelTracker.startTracking() accepts no parameters, a single
>> String, or a Collection.  The strings are the names of
>> components that you need.  It'll track instances of ComponentResolver,
>> maintaining a list of what components are available and what
>> components are still needed.  When all the components you need are
>> available, it'll call start(); when any of the components cease to be
>> available, it'll call stop().
>>
>> If you don't supply component names, it'll react to camel-core itself
>> becoming active, which is all you need for core components like mock,
>> bean and file.
>>
>> Use routeId() in your route definitions.  Use
>> camelcontext.startRoute() from the OsgiCamelTracker.start(); use
>> camelcontext.stopRoute() from the OsgiCamelTracker.stop().
>>
>> Be advised, you'll need to use a singleton CamelContext if you're
>> using SEDA queues, because SEDA queues are local to a CamelContext
>> instance.  A route that consumes from a SEDA queue from one
>> CamelContext instance won't see anything produced to a SEDA queue from
>> a different CamelContext instance.
>>
>> For OsgiDefaultCamelContext...
>>
>>> On Mon, Jun 20, 2011 at 3:31 PM, Michael Furtak  wrote:
>>>> I did come across mention of this in my troubleshooting exploration. It 
>>>> seems to be part of a bundle called camel-core-osgi, is that right? I 
>>>> don't think I have it in my 2.7.2 distribution. Is it something I need to 
>>>> bundle myself? I also saw mention of it being private to the Spring 
>>>> bundle, which is what prompted my discussion about not wanting to bring in 
>>>> Spring.
>>
>> org.apache.camel.core.osgi is in camel-blueprint.jar.  I split it out
>> into its own .jar so as to not worry about the Blueprint dependencies.
>>  You'll need to modify the manifest, or make your own.
>>
>> Don
>>
>>
>

Re: Camel under OSGi without Spring et al.

[Donald Whytock]

Odd...I can see it there.  I'll send it to you directly.

Don

On Tue, Jun 21, 2011 at 8:01 AM, Michael Furtak  wrote:
> Hi Don,
>
> I wasn't able to find OsgiCamelTracker.java attached to your message.
>
> Thanks,
> -Mike
>
>
>
>
>
>
>
> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. 
> IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
> DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
> use of this message for any purpose is strictly prohibited. If you have 
> received this communication in error, please delete the message and notify 
> the sender so that we may correct our records.
>
> -Original Message-
>
>
>
> From: Donald Whytock [mailto:dwhyt...@gmail.com]
> Sent: Monday, June 20, 2011 4:45 PM
> To: users@camel.apache.org
> Subject: Re: Camel under OSGi without Spring et al.
>
> OsgiCamelTracker.java (attached) is a work in progress.  There's a
> reference to ContextUtil; that's the service class that supplies the
> CamelContext singleton.
>
> Use it by subclassing it and implementing methods start() and stop().
> Call setBundleContext(bundleContext) first, then startTracking().
>
> OsgiCamelTracker.startTracking() accepts no parameters, a single
> String, or a Collection.  The strings are the names of
> components that you need.  It'll track instances of ComponentResolver,
> maintaining a list of what components are available and what
> components are still needed.  When all the components you need are
> available, it'll call start(); when any of the components cease to be
> available, it'll call stop().
>
> If you don't supply component names, it'll react to camel-core itself
> becoming active, which is all you need for core components like mock,
> bean and file.
>
> Use routeId() in your route definitions.  Use
> camelcontext.startRoute() from the OsgiCamelTracker.start(); use
> camelcontext.stopRoute() from the OsgiCamelTracker.stop().
>
> Be advised, you'll need to use a singleton CamelContext if you're
> using SEDA queues, because SEDA queues are local to a CamelContext
> instance.  A route that consumes from a SEDA queue from one
> CamelContext instance won't see anything produced to a SEDA queue from
> a different CamelContext instance.
>
> For OsgiDefaultCamelContext...
>
>> On Mon, Jun 20, 2011 at 3:31 PM, Michael Furtak  wrote:
>>> I did come across mention of this in my troubleshooting exploration. It 
>>> seems to be part of a bundle called camel-core-osgi, is that right? I don't 
>>> think I have it in my 2.7.2 distribution. Is it something I need to bundle 
>>> myself? I also saw mention of it being private to the Spring bundle, which 
>>> is what prompted my discussion about not wanting to bring in Spring.
>
> org.apache.camel.core.osgi is in camel-blueprint.jar.  I split it out
> into its own .jar so as to not worry about the Blueprint dependencies.
>  You'll need to modify the manifest, or make your own.
>
> Don
>
>

RE: Camel under OSGi without Spring et al.

[Michael Furtak]

Hi Don,

I wasn't able to find OsgiCamelTracker.java attached to your message.

Thanks,
-Mike







THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT 
MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.

-Original Message-



From: Donald Whytock [mailto:dwhyt...@gmail.com]
Sent: Monday, June 20, 2011 4:45 PM
To: users@camel.apache.org
Subject: Re: Camel under OSGi without Spring et al.

OsgiCamelTracker.java (attached) is a work in progress.  There's a
reference to ContextUtil; that's the service class that supplies the
CamelContext singleton.

Use it by subclassing it and implementing methods start() and stop().
Call setBundleContext(bundleContext) first, then startTracking().

OsgiCamelTracker.startTracking() accepts no parameters, a single
String, or a Collection.  The strings are the names of
components that you need.  It'll track instances of ComponentResolver,
maintaining a list of what components are available and what
components are still needed.  When all the components you need are
available, it'll call start(); when any of the components cease to be
available, it'll call stop().

If you don't supply component names, it'll react to camel-core itself
becoming active, which is all you need for core components like mock,
bean and file.

Use routeId() in your route definitions.  Use
camelcontext.startRoute() from the OsgiCamelTracker.start(); use
camelcontext.stopRoute() from the OsgiCamelTracker.stop().

Be advised, you'll need to use a singleton CamelContext if you're
using SEDA queues, because SEDA queues are local to a CamelContext
instance.  A route that consumes from a SEDA queue from one
CamelContext instance won't see anything produced to a SEDA queue from
a different CamelContext instance.

For OsgiDefaultCamelContext...

> On Mon, Jun 20, 2011 at 3:31 PM, Michael Furtak  wrote:
>> I did come across mention of this in my troubleshooting exploration. It 
>> seems to be part of a bundle called camel-core-osgi, is that right? I don't 
>> think I have it in my 2.7.2 distribution. Is it something I need to bundle 
>> myself? I also saw mention of it being private to the Spring bundle, which 
>> is what prompted my discussion about not wanting to bring in Spring.

org.apache.camel.core.osgi is in camel-blueprint.jar.  I split it out
into its own .jar so as to not worry about the Blueprint dependencies.
 You'll need to modify the manifest, or make your own.

Don

Re: Camel under OSGi without Spring et al.

[Willem Jiang]

Please try the latest Camel 2.8-SNAPSHOT.
The patch wasn't merged to Camel 2.7.x.

On 6/21/11 3:46 PM, Christian Schneider wrote:

Hi Willem,

that did not work for me. The bundle camel-core-osgi does not seem to
export the package org.apache.camel.core.osgi.
It is in Ignore-Packages.

Christian


Am 21.06.2011 09:39, schrieb Willem Jiang:

Hi Christian

You can create the OsgiDefaultCamelContext directly when you install
the camel-core-osgi bundle.

DefaultCamelContext camelContext = new OsgiDefaultCamelContext(context);

The CamelContextFactory is designed as a factory bean for spring to use.

Willem





--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
 http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Re: Camel under OSGi without Spring et al.

[Christian Schneider]

Hi Willem,

that did not work for me. The bundle camel-core-osgi does not seem to 
export the package org.apache.camel.core.osgi.

It is in Ignore-Packages.

Christian


Am 21.06.2011 09:39, schrieb Willem Jiang:

Hi Christian

 You can create the OsgiDefaultCamelContext directly when you install 
the camel-core-osgi bundle.


 DefaultCamelContext camelContext = new OsgiDefaultCamelContext(context);

The CamelContextFactory is designed as a factory bean for spring to use.

Willem


--
--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: Camel under OSGi without Spring et al.

[Willem Jiang]

Hi Christian

 You can create the OsgiDefaultCamelContext directly when you install 
the camel-core-osgi bundle.


 DefaultCamelContext camelContext = new OsgiDefaultCamelContext(context);

The CamelContextFactory is designed as a factory bean for spring to use.

Willem

On 6/21/11 1:23 PM, Christian Schneider wrote:

Hi Willem and Mike,

I just tried to use the OsgiDefaultCamelContext in OSGi. This is not
directly possbile as the package is not exported.
In the end I found that there is a CamelContextFactory in camel-spring
that can be used to instantiate a camel context.

It works like this in the Activator:

CamelContextFactory factory = new CamelContextFactory();
factory.setBundleContext(context);
DefaultCamelContext camelContext = factory.createContext();

I wonder a bit why this clearly OSGi specific class is in camel-spring.
I would have expected it rather in camel-core-osgi.
In any case it seems to be the only way to instantiate the camel context
programmatically in OSGi.

Christian


Am 21.06.2011 04:51, schrieb Willem Jiang:

Just FYI, the camel-core-osgi bundle will be published in the Camel
2.8.0. You can find more information here[1]

[1]https://issues.apache.org/jira/browse/CAMEL-3814

On 6/21/11 3:31 AM, Michael Furtak wrote:

i Don,

The exception was:

org.apache.camel.TypeConverterLoaderException: Failed to load type
converters because of: Cannot find any type converter classes from
the following packages: [org.apache.camel.component.file,
org.apache.camel.component.bean, org.apache.camel.converter]

Which I assume has to do with trying to use a normal CamelContext in
an OSGi environment. So, OsgiDefaultCamelContext...

I did come across mention of this in my troubleshooting exploration.
It seems to be part of a bundle called camel-core-osgi, is that
right? I don't think I have it in my 2.7.2 distribution. Is it
something I need to bundle myself? I also saw mention of it being
private to the Spring bundle, which is what prompted my discussion
about not wanting to bring in Spring.

Any further info would be most helpful.

Thanks,
-Mike









--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
 http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Re: Camel under OSGi without Spring et al.

[Christian Schneider]

Hi Willem and Mike,

I just tried to use the OsgiDefaultCamelContext in OSGi. This is not 
directly possbile as the package is not exported.
In the end I found that there is a CamelContextFactory in camel-spring 
that can be used to instantiate a camel context.


It works like this in the Activator:

CamelContextFactory factory = new CamelContextFactory();
factory.setBundleContext(context);
DefaultCamelContext camelContext = factory.createContext();

I wonder a bit why this clearly OSGi specific class is in camel-spring. 
I would have expected it rather in camel-core-osgi.
In any case it seems to be the only way to instantiate the camel context 
programmatically in OSGi.


Christian


Am 21.06.2011 04:51, schrieb Willem Jiang:
Just FYI, the camel-core-osgi bundle will be published in the Camel 
2.8.0. You can find more information here[1]


[1]https://issues.apache.org/jira/browse/CAMEL-3814

On 6/21/11 3:31 AM, Michael Furtak wrote:

i Don,

The exception was:

org.apache.camel.TypeConverterLoaderException: Failed to load type 
converters because of: Cannot find any type converter classes from 
the following packages: [org.apache.camel.component.file, 
org.apache.camel.component.bean, org.apache.camel.converter]


Which I assume has to do with trying to use a normal CamelContext in 
an OSGi environment. So, OsgiDefaultCamelContext...


I did come across mention of this in my troubleshooting exploration. 
It seems to be part of a bundle called camel-core-osgi, is that 
right? I don't think I have it in my 2.7.2 distribution. Is it 
something I need to bundle myself? I also saw mention of it being 
private to the Spring bundle, which is what prompted my discussion 
about not wanting to bring in Spring.


Any further info would be most helpful.

Thanks,
-Mike






--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: Camel under OSGi without Spring et al.

[Willem Jiang]

Just FYI, the camel-core-osgi bundle will be published in the Camel 
2.8.0. You can find more information here[1]


[1]https://issues.apache.org/jira/browse/CAMEL-3814

On 6/21/11 3:31 AM, Michael Furtak wrote:

i Don,

The exception was:

org.apache.camel.TypeConverterLoaderException: Failed to load type converters 
because of: Cannot find any type converter classes from the following packages: 
[org.apache.camel.component.file, org.apache.camel.component.bean, 
org.apache.camel.converter]

Which I assume has to do with trying to use a normal CamelContext in an OSGi 
environment. So, OsgiDefaultCamelContext...

I did come across mention of this in my troubleshooting exploration. It seems 
to be part of a bundle called camel-core-osgi, is that right? I don't think I 
have it in my 2.7.2 distribution. Is it something I need to bundle myself? I 
also saw mention of it being private to the Spring bundle, which is what 
prompted my discussion about not wanting to bring in Spring.

Any further info would be most helpful.

Thanks,
-Mike




--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
 http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

RE: Camel under OSGi without Spring et al.

[Michael Furtak]

Hi Hadrian,

Aha, that explains it. Thanks!

-Mike







THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT 
MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.

-Original Message-



From: Hadrian Zbarcea [mailto:hzbar...@gmail.com]
Sent: Monday, June 20, 2011 3:45 PM
To: users@camel.apache.org
Subject: Re: Camel under OSGi without Spring et al.

Hi,

You are correct. There is also a camel-blueprint you may want to look at
[1]. Regarding the absence of camel-core-osgi from the kit, that's
actually a problem that was reported earlier today [2]. We use maven so
much that we missed the absence of some of the jars from the official
distro. Please grab the missing jars from the maven central repository
[3] (and maybe [4]).

Regards,
Hadrian

[1] http://camel.apache.org/using-osgi-blueprint-with-camel.html
[2] https://issues.apache.org/jira/browse/CAMEL-4125
[3] http://repo1.maven.org/maven2/org/apache/camel/camel-core-osgi/2.7.2/
[4] http://repo1.maven.org/maven2/org/apache/camel/camel-core-xml/2.7.2/



On 06/20/2011 03:31 PM, Michael Furtak wrote:
> Hi Don,
>
> The exception was:
>
> org.apache.camel.TypeConverterLoaderException: Failed to load type converters 
> because of: Cannot find any type converter classes from the following 
> packages: [org.apache.camel.component.file, org.apache.camel.component.bean, 
> org.apache.camel.converter]
>
> Which I assume has to do with trying to use a normal CamelContext in an OSGi 
> environment. So, OsgiDefaultCamelContext...
>
> I did come across mention of this in my troubleshooting exploration. It seems 
> to be part of a bundle called camel-core-osgi, is that right? I don't think I 
> have it in my 2.7.2 distribution. Is it something I need to bundle myself? I 
> also saw mention of it being private to the Spring bundle, which is what 
> prompted my discussion about not wanting to bring in Spring.
>
> Any further info would be most helpful.
>
> Thanks,
> -Mike
>
>
>
>
>
>
>
> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. 
> IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
> DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
> use of this message for any purpose is strictly prohibited. If you have 
> received this communication in error, please delete the message and notify 
> the sender so that we may correct our records.
>
> -Original Message-
>
>
>
> From: Donald Whytock [mailto:dwhyt...@gmail.com]
> Sent: Monday, June 20, 2011 3:10 PM
> To: users@camel.apache.org
> Subject: Re: Camel under OSGi without Spring et al.
>
> Hi Michael,
>
> Yes, it's possible.  I do it myself.  I create my routes in Java, and
> I use a service that supplies a singleton CamelContext based on
> OsgiDefaultCamelContext.
>
> What specific problems are you having?
>
> Don
>
> On Mon, Jun 20, 2011 at 2:48 PM, Michael Furtak  wrote:
>> Hi all,
>>
>> I have an existing OSGi (Equinox) application into which I would like to 
>> introduce Camel. I'm quite new to Camel, but I've not had much luck with my 
>> efforts so far. My problem seems to match that which is discussed in this 
>> thread:
>>
>> http://camel.465427.n5.nabble.com/TypeConverters-in-OSGi-td2802220.html
>>
>>  From what I can see, discussions of Camel and OSGi seem to involve Karaf, 
>> ServiceMix and/or Spring. Is it possible to use Camel in an OSGi environment 
>> without one of those higher level abstractions? The resolution of that 
>> thread seems to be to "include Spring", but my application is not 
>> Spring-based, and I would prefer not to introduce that dependency if at all 
>> possible.
>>
>> Thanks in advance for your advice,
>>
>> +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +
>> Michael Furtak
>> Software Engineer
>> Cognitive Systems
>> Government Services
>> Charles River Analytics Inc.
>> 617.491.3474 x534
>> www.cra.com<http://www.cra.com/>
>>
>>
>>
>>
>>
>> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. 
>> IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
>> DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
>> use of this message for any purpose is strictly prohibited. If you have 
>> received this communication in error, please delete the message and notify 
>> the sender so that we may correct our records.
>>
>>
>>
>>
>

Re: Camel under OSGi without Spring et al.

[Donald Whytock]

OsgiCamelTracker.java (attached) is a work in progress.  There's a
reference to ContextUtil; that's the service class that supplies the
CamelContext singleton.

Use it by subclassing it and implementing methods start() and stop().
Call setBundleContext(bundleContext) first, then startTracking().

OsgiCamelTracker.startTracking() accepts no parameters, a single
String, or a Collection.  The strings are the names of
components that you need.  It'll track instances of ComponentResolver,
maintaining a list of what components are available and what
components are still needed.  When all the components you need are
available, it'll call start(); when any of the components cease to be
available, it'll call stop().

If you don't supply component names, it'll react to camel-core itself
becoming active, which is all you need for core components like mock,
bean and file.

Use routeId() in your route definitions.  Use
camelcontext.startRoute() from the OsgiCamelTracker.start(); use
camelcontext.stopRoute() from the OsgiCamelTracker.stop().

Be advised, you'll need to use a singleton CamelContext if you're
using SEDA queues, because SEDA queues are local to a CamelContext
instance.  A route that consumes from a SEDA queue from one
CamelContext instance won't see anything produced to a SEDA queue from
a different CamelContext instance.

For OsgiDefaultCamelContext...

> On Mon, Jun 20, 2011 at 3:31 PM, Michael Furtak  wrote:
>> I did come across mention of this in my troubleshooting exploration. It 
>> seems to be part of a bundle called camel-core-osgi, is that right? I don't 
>> think I have it in my 2.7.2 distribution. Is it something I need to bundle 
>> myself? I also saw mention of it being private to the Spring bundle, which 
>> is what prompted my discussion about not wanting to bring in Spring.

org.apache.camel.core.osgi is in camel-blueprint.jar.  I split it out
into its own .jar so as to not worry about the Blueprint dependencies.
 You'll need to modify the manifest, or make your own.

Don

Re: Camel under OSGi without Spring et al.

[Donald Whytock]

Yeah, I had that.  In an OSGi environment, you don't have
TypeConverters available until they've been registered as services by
the Camel bundles.  I built something that uses a ServiceTracker to
listen for instances of org.apache.camel.spi.ComponentResolver.  One
is launched with the camel-core bundle; others are launched with the
component bundles.  You need there to be something that matches the
filter

"((&" + Constants.OBJECTCLASS + "=" + ComponentResolver.class.getName()
   + ")(component=" +  + "))"

So that you know all the components are there before you start apps
that depend on them.

I can attach a couple samples shortly.

Don

On Mon, Jun 20, 2011 at 3:31 PM, Michael Furtak  wrote:
> Hi Don,
>
> The exception was:
>
> org.apache.camel.TypeConverterLoaderException: Failed to load type converters 
> because of: Cannot find any type converter classes from the following 
> packages: [org.apache.camel.component.file, org.apache.camel.component.bean, 
> org.apache.camel.converter]
>
> Which I assume has to do with trying to use a normal CamelContext in an OSGi 
> environment. So, OsgiDefaultCamelContext...
>
> I did come across mention of this in my troubleshooting exploration. It seems 
> to be part of a bundle called camel-core-osgi, is that right? I don't think I 
> have it in my 2.7.2 distribution. Is it something I need to bundle myself? I 
> also saw mention of it being private to the Spring bundle, which is what 
> prompted my discussion about not wanting to bring in Spring.
>
> Any further info would be most helpful.
>
> Thanks,
> -Mike
>
>
>
>
>
>
>
> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. 
> IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
> DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
> use of this message for any purpose is strictly prohibited. If you have 
> received this communication in error, please delete the message and notify 
> the sender so that we may correct our records.
>
> -----Original Message-
>
>
>
> From: Donald Whytock [mailto:dwhyt...@gmail.com]
> Sent: Monday, June 20, 2011 3:10 PM
> To: users@camel.apache.org
> Subject: Re: Camel under OSGi without Spring et al.
>
> Hi Michael,
>
> Yes, it's possible.  I do it myself.  I create my routes in Java, and
> I use a service that supplies a singleton CamelContext based on
> OsgiDefaultCamelContext.
>
> What specific problems are you having?
>
> Don
>
> On Mon, Jun 20, 2011 at 2:48 PM, Michael Furtak  wrote:
>> Hi all,
>>
>> I have an existing OSGi (Equinox) application into which I would like to 
>> introduce Camel. I'm quite new to Camel, but I've not had much luck with my 
>> efforts so far. My problem seems to match that which is discussed in this 
>> thread:
>>
>> http://camel.465427.n5.nabble.com/TypeConverters-in-OSGi-td2802220.html
>>
>> From what I can see, discussions of Camel and OSGi seem to involve Karaf, 
>> ServiceMix and/or Spring. Is it possible to use Camel in an OSGi environment 
>> without one of those higher level abstractions? The resolution of that 
>> thread seems to be to "include Spring", but my application is not 
>> Spring-based, and I would prefer not to introduce that dependency if at all 
>> possible.
>>
>> Thanks in advance for your advice,
>>
>> +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +
>> Michael Furtak
>> Software Engineer
>> Cognitive Systems
>> Government Services
>> Charles River Analytics Inc.
>> 617.491.3474 x534
>> www.cra.com<http://www.cra.com/>
>>
>>
>>
>>
>>
>> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. 
>> IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
>> DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
>> use of this message for any purpose is strictly prohibited. If you have 
>> received this communication in error, please delete the message and notify 
>> the sender so that we may correct our records.
>>
>>
>>
>>
>
>

Re: Camel under OSGi without Spring et al.

[Hadrian Zbarcea]

Hi,

You are correct. There is also a camel-blueprint you may want to look at 
[1]. Regarding the absence of camel-core-osgi from the kit, that's 
actually a problem that was reported earlier today [2]. We use maven so 
much that we missed the absence of some of the jars from the official 
distro. Please grab the missing jars from the maven central repository 
[3] (and maybe [4]).


Regards,
Hadrian

[1] http://camel.apache.org/using-osgi-blueprint-with-camel.html
[2] https://issues.apache.org/jira/browse/CAMEL-4125
[3] http://repo1.maven.org/maven2/org/apache/camel/camel-core-osgi/2.7.2/
[4] http://repo1.maven.org/maven2/org/apache/camel/camel-core-xml/2.7.2/



On 06/20/2011 03:31 PM, Michael Furtak wrote:

Hi Don,

The exception was:

org.apache.camel.TypeConverterLoaderException: Failed to load type converters 
because of: Cannot find any type converter classes from the following packages: 
[org.apache.camel.component.file, org.apache.camel.component.bean, 
org.apache.camel.converter]

Which I assume has to do with trying to use a normal CamelContext in an OSGi 
environment. So, OsgiDefaultCamelContext...

I did come across mention of this in my troubleshooting exploration. It seems 
to be part of a bundle called camel-core-osgi, is that right? I don't think I 
have it in my 2.7.2 distribution. Is it something I need to bundle myself? I 
also saw mention of it being private to the Spring bundle, which is what 
prompted my discussion about not wanting to bring in Spring.

Any further info would be most helpful.

Thanks,
-Mike







THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT 
MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.

-Original Message-



From: Donald Whytock [mailto:dwhyt...@gmail.com]
Sent: Monday, June 20, 2011 3:10 PM
To: users@camel.apache.org
Subject: Re: Camel under OSGi without Spring et al.

Hi Michael,

Yes, it's possible.  I do it myself.  I create my routes in Java, and
I use a service that supplies a singleton CamelContext based on
OsgiDefaultCamelContext.

What specific problems are you having?

Don

On Mon, Jun 20, 2011 at 2:48 PM, Michael Furtak  wrote:

Hi all,

I have an existing OSGi (Equinox) application into which I would like to 
introduce Camel. I'm quite new to Camel, but I've not had much luck with my 
efforts so far. My problem seems to match that which is discussed in this 
thread:

http://camel.465427.n5.nabble.com/TypeConverters-in-OSGi-td2802220.html

 From what I can see, discussions of Camel and OSGi seem to involve Karaf, ServiceMix 
and/or Spring. Is it possible to use Camel in an OSGi environment without one of those 
higher level abstractions? The resolution of that thread seems to be to "include 
Spring", but my application is not Spring-based, and I would prefer not to introduce 
that dependency if at all possible.

Thanks in advance for your advice,

+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +
Michael Furtak
Software Engineer
Cognitive Systems
Government Services
Charles River Analytics Inc.
617.491.3474 x534
www.cra.com<http://www.cra.com/>





THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT 
MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.

RE: Camel under OSGi without Spring et al.

[Michael Furtak]

Hi Don,

The exception was:

org.apache.camel.TypeConverterLoaderException: Failed to load type converters 
because of: Cannot find any type converter classes from the following packages: 
[org.apache.camel.component.file, org.apache.camel.component.bean, 
org.apache.camel.converter]

Which I assume has to do with trying to use a normal CamelContext in an OSGi 
environment. So, OsgiDefaultCamelContext...

I did come across mention of this in my troubleshooting exploration. It seems 
to be part of a bundle called camel-core-osgi, is that right? I don't think I 
have it in my 2.7.2 distribution. Is it something I need to bundle myself? I 
also saw mention of it being private to the Spring bundle, which is what 
prompted my discussion about not wanting to bring in Spring.

Any further info would be most helpful.

Thanks,
-Mike







THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT 
MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.

-Original Message-



From: Donald Whytock [mailto:dwhyt...@gmail.com]
Sent: Monday, June 20, 2011 3:10 PM
To: users@camel.apache.org
Subject: Re: Camel under OSGi without Spring et al.

Hi Michael,

Yes, it's possible.  I do it myself.  I create my routes in Java, and
I use a service that supplies a singleton CamelContext based on
OsgiDefaultCamelContext.

What specific problems are you having?

Don

On Mon, Jun 20, 2011 at 2:48 PM, Michael Furtak  wrote:
> Hi all,
>
> I have an existing OSGi (Equinox) application into which I would like to 
> introduce Camel. I'm quite new to Camel, but I've not had much luck with my 
> efforts so far. My problem seems to match that which is discussed in this 
> thread:
>
> http://camel.465427.n5.nabble.com/TypeConverters-in-OSGi-td2802220.html
>
> From what I can see, discussions of Camel and OSGi seem to involve Karaf, 
> ServiceMix and/or Spring. Is it possible to use Camel in an OSGi environment 
> without one of those higher level abstractions? The resolution of that thread 
> seems to be to "include Spring", but my application is not Spring-based, and 
> I would prefer not to introduce that dependency if at all possible.
>
> Thanks in advance for your advice,
>
> +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +
> Michael Furtak
> Software Engineer
> Cognitive Systems
> Government Services
> Charles River Analytics Inc.
> 617.491.3474 x534
> www.cra.com<http://www.cra.com/>
>
>
>
>
>
> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. 
> IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
> DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
> use of this message for any purpose is strictly prohibited. If you have 
> received this communication in error, please delete the message and notify 
> the sender so that we may correct our records.
>
>
>
>

Re: Camel under OSGi without Spring et al.

[Donald Whytock]

Hi Michael,

Yes, it's possible.  I do it myself.  I create my routes in Java, and
I use a service that supplies a singleton CamelContext based on
OsgiDefaultCamelContext.

What specific problems are you having?

Don

On Mon, Jun 20, 2011 at 2:48 PM, Michael Furtak  wrote:
> Hi all,
>
> I have an existing OSGi (Equinox) application into which I would like to 
> introduce Camel. I'm quite new to Camel, but I've not had much luck with my 
> efforts so far. My problem seems to match that which is discussed in this 
> thread:
>
> http://camel.465427.n5.nabble.com/TypeConverters-in-OSGi-td2802220.html
>
> From what I can see, discussions of Camel and OSGi seem to involve Karaf, 
> ServiceMix and/or Spring. Is it possible to use Camel in an OSGi environment 
> without one of those higher level abstractions? The resolution of that thread 
> seems to be to "include Spring", but my application is not Spring-based, and 
> I would prefer not to introduce that dependency if at all possible.
>
> Thanks in advance for your advice,
>
> +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +
> Michael Furtak
> Software Engineer
> Cognitive Systems
> Government Services
> Charles River Analytics Inc.
> 617.491.3474 x534
> www.cra.com
>
>
>
>
>
> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. 
> IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
> DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
> use of this message for any purpose is strictly prohibited. If you have 
> received this communication in error, please delete the message and notify 
> the sender so that we may correct our records.
>
>
>
>

Camel under OSGi without Spring et al.

[Michael Furtak]

Hi all,

I have an existing OSGi (Equinox) application into which I would like to 
introduce Camel. I'm quite new to Camel, but I've not had much luck with my 
efforts so far. My problem seems to match that which is discussed in this 
thread:

http://camel.465427.n5.nabble.com/TypeConverters-in-OSGi-td2802220.html

>From what I can see, discussions of Camel and OSGi seem to involve Karaf, 
>ServiceMix and/or Spring. Is it possible to use Camel in an OSGi environment 
>without one of those higher level abstractions? The resolution of that thread 
>seems to be to "include Spring", but my application is not Spring-based, and I 
>would prefer not to introduce that dependency if at all possible.

Thanks in advance for your advice,

+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +
Michael Furtak
Software Engineer
Cognitive Systems
Government Services
Charles River Analytics Inc.
617.491.3474 x534
www.cra.com





THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT 
MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.