Loading TypeConverters in OSGi with Camel 2.0 RC1

[Martin Krasser <de...@martin-krasser.de>]

Hi,

I'm playing with Camel 2.0 in OSGi (Equinox) and found that 
TypeConverters are loaded by camel-osgi only from bundles that have been 
STARTED. The reason why TypeConverter loading from RESOLVED bundles 
doesn't work is that the OsgiPackageScanClassResolver relies on a 
BundleContext which is null for bundles in RESOLVED state (as required 
by the OSGi spec 4.1 section 4.3.17). This leads to a 
NullPointerException. If it should be possible by design that 
TypeConverters can also be loaded from bundles in RESOLVED state, please 
let me know then I'll try to create a patch.

Btw, great work that you all did for Camel 2.0. It's a pleasure to work 
with it!

Thanks,
Martin

Re: Loading TypeConverters in OSGi with Camel 2.0 RC1

[Claus Ibsen <cl...@gmail.com>]

Martin

Thanks for the patch.

I assume it just works around whens bundle are not STARTED. And in
case its STARTED later it wont be picked up?

Maybe the overall strategy should be to listen for bundle activity and
be able to register type converters when a bundle changes it stare to
STARTED.
And when its removed again, it should be able to unregister the type
converters as well.

But that also holds true for components and whatnot :) Which
potentially also could be STOPPED etc.
So this may be part of a bigger issue.




On Mon, Aug 24, 2009 at 5:34 PM, Claus Ibsen<cl...@gmail.com> wrote:
> On Mon, Aug 24, 2009 at 4:38 PM, Martin Krasser<de...@martin-krasser.de> wrote:
>> Hi,
>>
>> I'm playing with Camel 2.0 in OSGi (Equinox) and found that TypeConverters
>> are loaded by camel-osgi only from bundles that have been STARTED. The
>> reason why TypeConverter loading from RESOLVED bundles doesn't work is that
>> the OsgiPackageScanClassResolver relies on a BundleContext which is null for
>> bundles in RESOLVED state (as required by the OSGi spec 4.1 section 4.3.17).
>> This leads to a NullPointerException. If it should be possible by design
>> that TypeConverters can also be loaded from bundles in RESOLVED state,
>> please let me know then I'll try to create a patch.
>>
>
> That would be fantastic, as it does cause a bit of pain as you need to
> have bundles started and loading in correct order
> for all the type converter stuff to work properly.
>
> G. Nodet from Apache Serviemix / Karaf also had some notes on this as well.
> There is a dicusssion on Camel Dev about it - title = Converter
> discover in OSGi.
>
> In the longer run I would like to rework the compoent loading to be
> more isolated and confined to per component base.
> So eg type converters are loaded as part of a component and not as now
> the only one discovered by classpath scanning at first need.
>
>
>
>
>> Btw, great work that you all did for Camel 2.0. It's a pleasure to work with
>> it!
>>
>
> Thanks. Hope your upgrade in IPF did go well.
>
>
>> Thanks,
>> Martin
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>



-- 
Claus Ibsen
Apache Camel Committer

Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus

Re: Loading TypeConverters in OSGi with Camel 2.0 RC1

[Claus Ibsen <cl...@gmail.com>]

On Mon, Aug 24, 2009 at 4:38 PM, Martin Krasser<de...@martin-krasser.de> wrote:
> Hi,
>
> I'm playing with Camel 2.0 in OSGi (Equinox) and found that TypeConverters
> are loaded by camel-osgi only from bundles that have been STARTED. The
> reason why TypeConverter loading from RESOLVED bundles doesn't work is that
> the OsgiPackageScanClassResolver relies on a BundleContext which is null for
> bundles in RESOLVED state (as required by the OSGi spec 4.1 section 4.3.17).
> This leads to a NullPointerException. If it should be possible by design
> that TypeConverters can also be loaded from bundles in RESOLVED state,
> please let me know then I'll try to create a patch.
>

That would be fantastic, as it does cause a bit of pain as you need to
have bundles started and loading in correct order
for all the type converter stuff to work properly.

G. Nodet from Apache Serviemix / Karaf also had some notes on this as well.
There is a dicusssion on Camel Dev about it - title = Converter
discover in OSGi.

In the longer run I would like to rework the compoent loading to be
more isolated and confined to per component base.
So eg type converters are loaded as part of a component and not as now
the only one discovered by classpath scanning at first need.

			


> Btw, great work that you all did for Camel 2.0. It's a pleasure to work with
> it!
>

Thanks. Hope your upgrade in IPF did go well.


> Thanks,
> Martin
>



-- 
Claus Ibsen
Apache Camel Committer

Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus