You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Freeman Fang <fr...@gmail.com> on 2011/01/10 10:32:05 UTC
[DISCUSS] how about specify camel feature bundle level less than 60.
Hi,
How about we specify start level for camel feature bundles less than
60, so that when restart servicemix, the camel related bundles always
get started before end users bundle, this can avoid lots of asyn
issues customer may encounter, such as camel component not available
yet when end users bundle get started.
Actually this discussion initially from fuse forum[1], and I'm not
very sure heavily depend on bundle start level is a good practice in
OSGi world, but I must admit that in servicemix camel should be
considered as a part of the framework, so give higher priority for
camel bundles seems OK.
Btw, karaf features already support specify start level, so it should
be doable in Servicemix to do it.
I'd like hear more voice, thoughts?
[1]http://fusesource.com/forums/thread.jspa?threadID=2493
TIA
Freeman
--
Freeman Fang
------------------------
FuseSource: http://fusesource.com
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang
Apache Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org
Apache Karaf: http://karaf.apache.org
Apache Felix: http://felix.apache.org
Re: [DISCUSS] how about specify camel feature bundle level less than 60.
Posted by Gert Vanthienen <ge...@gmail.com>.
Willem,
For the console, a System.out would work just fine because that gets
printed out nicely underneath the command. Not sure if we already
have another mechanism in place (e.g. to send the notification to the
web console if people are using that)...
If we add the timeout to the resolver, they don't necessarily need to
refresh the client bundle -- they just have to add the component
feature for the component to become available.
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Mon, Jan 10, 2011 at 2:54 PM, Willem Jiang <wi...@gmail.com> wrote:
> +1 for set the camel bundle start up level.
>
> If the client Camel application failed to resolve the component we still
> need to find a way to notify the user to refresh the client customer bundle.
>
> Does Karaf or ServiceMix has this kind notifcation other then the system
> out.
>
> Willem
>
> On 1/10/11 7:03 PM, Gert Vanthienen wrote:
>>
>> Freeman,
>>
>>
>> It would certainly make sense to lower the start level for the default
>> installed features. I even think we should consider lowering it and
>> 'hiding' them from the list, as they're just the system running
>> (similar to what happens with the default Karaf bundles). This will
>> make it easier for users to find their own bundles in the list that
>> remains.
>>
>> For optionally installed features, we could also lower the start level
>> on those, I guess -- given the limited impact of the bundle start
>> level, I don't see a real issue there. For things like optional Camel
>> components, that might make sense and it would solve some more
>> problems during startup. Let's say we make the default features start
>> level 40 and the optional ones start level 50 or something like that.
>>
>> However, it would be even better if we could also improve the way
>> Camel looks up components by adding the possibility for a timeout when
>> you're in an OSGi environment. The start level will fix most default
>> Camel components, but as soon as someone start relying on a
>> ComponentResolver being available in the registry, they can still run
>> into timing issues. Adding the timeout would fix that bit and, if we
>> provide some nice feedback on the console when we hit the timeout, we
>> can also improve user experience when they're installing a route
>> without installing the required component first (I've done this myself
>> quite a few times, so there must be other folks out there that make
>> the same mistake sometimes ;) ).
>>
>> Something like:
>> karaf@root> osgi:install -s mvn:my.camel.project:bundle:1.0
>> Bundle id: 170
>> Waiting for component jcr:
>> karaf@root> features:install camel-jcr
>> Component jcr: found
>>
>>
>> Regards,
>>
>> Gert Vanthienen
>> ------------------------
>> FuseSource
>> Web: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>>
>>
>>
>> On Mon, Jan 10, 2011 at 10:32 AM, Freeman Fang<fr...@gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> How about we specify start level for camel feature bundles less than 60,
>>> so
>>> that when restart servicemix, the camel related bundles always get
>>> started
>>> before end users bundle, this can avoid lots of asyn issues customer
>>> may
>>> encounter, such as camel component not available yet when end users
>>> bundle
>>> get started.
>>>
>>> Actually this discussion initially from fuse forum[1], and I'm not very
>>> sure
>>> heavily depend on bundle start level is a good practice in OSGi world,
>>> but
>>> I must admit that in servicemix camel should be considered as a part of
>>> the
>>> framework, so give higher priority for camel bundles seems OK.
>>> Btw, karaf features already support specify start level, so it should be
>>> doable in Servicemix to do it.
>>>
>>> I'd like hear more voice, thoughts?
>>>
>>> [1]http://fusesource.com/forums/thread.jspa?threadID=2493
>>>
>>> TIA
>>> Freeman
>>>
>>> --
>>> Freeman Fang
>>>
>>> ------------------------
>>>
>>> FuseSource: http://fusesource.com
>>> blog: http://freemanfang.blogspot.com
>>> twitter: http://twitter.com/freemanfang
>>> Apache Servicemix:http://servicemix.apache.org
>>> Apache Cxf: http://cxf.apache.org
>>> Apache Karaf: http://karaf.apache.org
>>> Apache Felix: http://felix.apache.org
>>>
>>>
>>
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
>
Re: [DISCUSS] how about specify camel feature bundle level less than
60.
Posted by Willem Jiang <wi...@gmail.com>.
+1 for set the camel bundle start up level.
If the client Camel application failed to resolve the component we still
need to find a way to notify the user to refresh the client customer bundle.
Does Karaf or ServiceMix has this kind notifcation other then the system
out.
Willem
On 1/10/11 7:03 PM, Gert Vanthienen wrote:
> Freeman,
>
>
> It would certainly make sense to lower the start level for the default
> installed features. I even think we should consider lowering it and
> 'hiding' them from the list, as they're just the system running
> (similar to what happens with the default Karaf bundles). This will
> make it easier for users to find their own bundles in the list that
> remains.
>
> For optionally installed features, we could also lower the start level
> on those, I guess -- given the limited impact of the bundle start
> level, I don't see a real issue there. For things like optional Camel
> components, that might make sense and it would solve some more
> problems during startup. Let's say we make the default features start
> level 40 and the optional ones start level 50 or something like that.
>
> However, it would be even better if we could also improve the way
> Camel looks up components by adding the possibility for a timeout when
> you're in an OSGi environment. The start level will fix most default
> Camel components, but as soon as someone start relying on a
> ComponentResolver being available in the registry, they can still run
> into timing issues. Adding the timeout would fix that bit and, if we
> provide some nice feedback on the console when we hit the timeout, we
> can also improve user experience when they're installing a route
> without installing the required component first (I've done this myself
> quite a few times, so there must be other folks out there that make
> the same mistake sometimes ;) ).
>
> Something like:
> karaf@root> osgi:install -s mvn:my.camel.project:bundle:1.0
> Bundle id: 170
> Waiting for component jcr:
> karaf@root> features:install camel-jcr
> Component jcr: found
>
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> FuseSource
> Web: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
>
> On Mon, Jan 10, 2011 at 10:32 AM, Freeman Fang<fr...@gmail.com> wrote:
>> Hi,
>>
>> How about we specify start level for camel feature bundles less than 60, so
>> that when restart servicemix, the camel related bundles always get started
>> before end users bundle, this can avoid lots of asyn issues customer may
>> encounter, such as camel component not available yet when end users bundle
>> get started.
>>
>> Actually this discussion initially from fuse forum[1], and I'm not very sure
>> heavily depend on bundle start level is a good practice in OSGi world, but
>> I must admit that in servicemix camel should be considered as a part of the
>> framework, so give higher priority for camel bundles seems OK.
>> Btw, karaf features already support specify start level, so it should be
>> doable in Servicemix to do it.
>>
>> I'd like hear more voice, thoughts?
>>
>> [1]http://fusesource.com/forums/thread.jspa?threadID=2493
>>
>> TIA
>> Freeman
>>
>> --
>> Freeman Fang
>>
>> ------------------------
>>
>> FuseSource: http://fusesource.com
>> blog: http://freemanfang.blogspot.com
>> twitter: http://twitter.com/freemanfang
>> Apache Servicemix:http://servicemix.apache.org
>> Apache Cxf: http://cxf.apache.org
>> Apache Karaf: http://karaf.apache.org
>> Apache Felix: http://felix.apache.org
>>
>>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Re: [DISCUSS] how about specify camel feature bundle level less than 60.
Posted by Gert Vanthienen <ge...@gmail.com>.
Freeman,
It would certainly make sense to lower the start level for the default
installed features. I even think we should consider lowering it and
'hiding' them from the list, as they're just the system running
(similar to what happens with the default Karaf bundles). This will
make it easier for users to find their own bundles in the list that
remains.
For optionally installed features, we could also lower the start level
on those, I guess -- given the limited impact of the bundle start
level, I don't see a real issue there. For things like optional Camel
components, that might make sense and it would solve some more
problems during startup. Let's say we make the default features start
level 40 and the optional ones start level 50 or something like that.
However, it would be even better if we could also improve the way
Camel looks up components by adding the possibility for a timeout when
you're in an OSGi environment. The start level will fix most default
Camel components, but as soon as someone start relying on a
ComponentResolver being available in the registry, they can still run
into timing issues. Adding the timeout would fix that bit and, if we
provide some nice feedback on the console when we hit the timeout, we
can also improve user experience when they're installing a route
without installing the required component first (I've done this myself
quite a few times, so there must be other folks out there that make
the same mistake sometimes ;) ).
Something like:
karaf@root> osgi:install -s mvn:my.camel.project:bundle:1.0
Bundle id: 170
Waiting for component jcr:
karaf@root> features:install camel-jcr
Component jcr: found
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Mon, Jan 10, 2011 at 10:32 AM, Freeman Fang <fr...@gmail.com> wrote:
> Hi,
>
> How about we specify start level for camel feature bundles less than 60, so
> that when restart servicemix, the camel related bundles always get started
> before end users bundle, this can avoid lots of asyn issues customer may
> encounter, such as camel component not available yet when end users bundle
> get started.
>
> Actually this discussion initially from fuse forum[1], and I'm not very sure
> heavily depend on bundle start level is a good practice in OSGi world, but
> I must admit that in servicemix camel should be considered as a part of the
> framework, so give higher priority for camel bundles seems OK.
> Btw, karaf features already support specify start level, so it should be
> doable in Servicemix to do it.
>
> I'd like hear more voice, thoughts?
>
> [1]http://fusesource.com/forums/thread.jspa?threadID=2493
>
> TIA
> Freeman
>
> --
> Freeman Fang
>
> ------------------------
>
> FuseSource: http://fusesource.com
> blog: http://freemanfang.blogspot.com
> twitter: http://twitter.com/freemanfang
> Apache Servicemix:http://servicemix.apache.org
> Apache Cxf: http://cxf.apache.org
> Apache Karaf: http://karaf.apache.org
> Apache Felix: http://felix.apache.org
>
>
Re: [DISCUSS] how about specify camel feature bundle level less than 60.
Posted by Freeman Fang <fr...@gmail.com>.
Just create SMX4-744[1] to take care of the camel bundle start level,
we can start with this issue and consider more framework start level
issue like specs, cxf, etc.
[1]https://issues.apache.org/jira/browse/SMX4-744
Freeman
On 2011-1-11, at 上午2:17, Jean-Baptiste Onofré wrote:
> Hi Dan,
>
> Totally agree. Gert already raised the Jira task about that.
>
> The only thing is to first release ServiceMix 4.3.0.
> Once it's done, we will used the OBR resolver (it will be included
> in ServiceMix 4.4.0).
>
> Anyway, I think that we can "classify" the bundle start level like
> this:
> 0 - low level system run level (OSGi related)
> 10 - kernel run level (related to Karaf bundles)
> 20 - API run level (JAXB API, SMX Specs, Geronimo Specs, etc)
> 30 - Impl run level (JAXB Impl, etc)
> 40 - Core application runtime (Aries Blueprint, Aries Transaction,
> etc)
> 50 - ServiceMix runtime (NMR, Camel, CXF, commands, JBI, etc)
> 100 - User applications (tiers bundles)
>
> It's more to document and provide a clean view to the end users.
>
> Regards
> JB
>
> On 01/10/2011 05:46 PM, Daniel Kulp wrote:
>>
>> I'm definitely in support of this as well. I'd actually suggest
>> taking it a
>> bit furthur and trying to define some sort of hiearchy of levels
>> and put
>> things in more apprioriate places.
>>
>> For example, it's definitely in the best interest of everything to
>> get most of
>> the "api" bundles started up ASAP. Otherwise, you can easily get
>> into
>> situations where some bundles use the "system" versions and othere
>> use the
>> bundle version and such. Thus, it might be good to say level 20
>> is for all
>> the API jars and 25 for the "impls" or similar, just to make sure
>> the API jars
>> are available real early. JAXB and JAX-WS API jars are really
>> affected by
>> this pretty badly, especially with the 2.2 versions being a bit
>> incompatible
>> with the version in the JDK.
>>
>> Dan
>>
>>
>> On Monday 10 January 2011 11:01:21 am Kurt Westerfeld wrote:
>>> I ran into a similar issue with system bundles being partially
>>> started with
>>> Apache ODE and related startup issues. It was my suggestion then
>>> to start
>>> system bundles< 60 and user bundles>60. Would this apply to all
>>> bundles
>>> that are supplied with features on SMX (like ODE), or just select
>>> ones?
>>> I'm highly in favor of this, btw.
>>>
>>>>>> Freeman Fang<fr...@gmail.com> 1/10/2011 4:32 AM>>>
>>>
>>> Hi,
>>>
>>> How about we specify start level for camel feature bundles less than
>>> 60, so that when restart servicemix, the camel related bundles
>>> always
>>> get started before end users bundle, this can avoid lots of asyn
>>> issues customer may encounter, such as camel component not available
>>> yet when end users bundle get started.
>>>
>>> Actually this discussion initially from fuse forum[1], and I'm not
>>> very sure heavily depend on bundle start level is a good practice
>>> in
>>> OSGi world, but I must admit that in servicemix camel should be
>>> considered as a part of the framework, so give higher priority for
>>> camel bundles seems OK.
>>> Btw, karaf features already support specify start level, so it
>>> should
>>> be doable in Servicemix to do it.
>>>
>>> I'd like hear more voice, thoughts?
>>>
>>> [1]http://fusesource.com/forums/thread.jspa?threadID=2493
>>>
>>> TIA
>>> Freeman
>>
--
Freeman Fang
------------------------
FuseSource: http://fusesource.com
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang
Apache Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org
Apache Karaf: http://karaf.apache.org
Apache Felix: http://felix.apache.org
Re: [DISCUSS] how about specify camel feature bundle level less than
60.
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Dan,
Totally agree. Gert already raised the Jira task about that.
The only thing is to first release ServiceMix 4.3.0.
Once it's done, we will used the OBR resolver (it will be included in
ServiceMix 4.4.0).
Anyway, I think that we can "classify" the bundle start level like this:
0 - low level system run level (OSGi related)
10 - kernel run level (related to Karaf bundles)
20 - API run level (JAXB API, SMX Specs, Geronimo Specs, etc)
30 - Impl run level (JAXB Impl, etc)
40 - Core application runtime (Aries Blueprint, Aries Transaction, etc)
50 - ServiceMix runtime (NMR, Camel, CXF, commands, JBI, etc)
100 - User applications (tiers bundles)
It's more to document and provide a clean view to the end users.
Regards
JB
On 01/10/2011 05:46 PM, Daniel Kulp wrote:
>
> I'm definitely in support of this as well. I'd actually suggest taking it a
> bit furthur and trying to define some sort of hiearchy of levels and put
> things in more apprioriate places.
>
> For example, it's definitely in the best interest of everything to get most of
> the "api" bundles started up ASAP. Otherwise, you can easily get into
> situations where some bundles use the "system" versions and othere use the
> bundle version and such. Thus, it might be good to say level 20 is for all
> the API jars and 25 for the "impls" or similar, just to make sure the API jars
> are available real early. JAXB and JAX-WS API jars are really affected by
> this pretty badly, especially with the 2.2 versions being a bit incompatible
> with the version in the JDK.
>
> Dan
>
>
> On Monday 10 January 2011 11:01:21 am Kurt Westerfeld wrote:
>> I ran into a similar issue with system bundles being partially started with
>> Apache ODE and related startup issues. It was my suggestion then to start
>> system bundles< 60 and user bundles>60. Would this apply to all bundles
>> that are supplied with features on SMX (like ODE), or just select ones?
>> I'm highly in favor of this, btw.
>>
>>>>> Freeman Fang<fr...@gmail.com> 1/10/2011 4:32 AM>>>
>>
>> Hi,
>>
>> How about we specify start level for camel feature bundles less than
>> 60, so that when restart servicemix, the camel related bundles always
>> get started before end users bundle, this can avoid lots of asyn
>> issues customer may encounter, such as camel component not available
>> yet when end users bundle get started.
>>
>> Actually this discussion initially from fuse forum[1], and I'm not
>> very sure heavily depend on bundle start level is a good practice in
>> OSGi world, but I must admit that in servicemix camel should be
>> considered as a part of the framework, so give higher priority for
>> camel bundles seems OK.
>> Btw, karaf features already support specify start level, so it should
>> be doable in Servicemix to do it.
>>
>> I'd like hear more voice, thoughts?
>>
>> [1]http://fusesource.com/forums/thread.jspa?threadID=2493
>>
>> TIA
>> Freeman
>
Re: [DISCUSS] how about specify camel feature bundle level less than 60.
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
Exactly -- start level only controls when a bundle get started, but
doesn't say anything about the services it provides or requires. As
Blueprint and Spring contexts get started asynchronously, services are
added to the service registry and become available for other bundles
to use.
Once again, I do agree we should try to get the bundle start level
configured properly to make a good distinction between the default
bundles and user applications being deployed later on. This might
prevent a few of the issues people are running into, but in general
bundles and their services should get started by the framework as
their dependencies become available, so that's what we should be
trying to accomplish.
In the original Camel problem, the real solution is in allowing the
component registry to wait for a moment while components are becoming
available -- that's what we need to leverage the benefits of the
dynamic nature of OSGi. A similar solution can be found in a lot of
OSGi technologies: blueprint will wait for services and namespace
handlers to become available, FileInstall will retry to deploy a
previously unknown file type as soon as new deployment options become
available, ...
I'm not sure what the exact problem is that ODE is facing, but if you
could give us some extra information there, I'm pretty sure we can
come up with an elegant solution for that as well. It's definitely
not a unique problem, so there are a lot of examples around in
projects like Aries and Felix that we could 'borrow' from.
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Mon, Jan 10, 2011 at 5:55 PM, Kurt Westerfeld <kw...@novell.com> wrote:
> There is also the case to handle where a "system" bundle is started, and a bundle tracker or something similar does an async start on a separate thread. Witness the extender bundle activation models--lots of threads starting asynchronously.
>
> This all OK, but fast-forward to the situation where something like Camel or ODE is providing infrastructure services that watch for user bundles later. The startup of Camel, I know nothing about, but in ODE's case it's starting a bunch of internal services, all the while the bundle is "started". Now, this may be a bug in the ODE code, but I don't think it's unique. I don't know what the right answer is here but I thought I'd point out that just getting a bundle to "started" state doesn't seem to always be the final answer.
>
>>>> Daniel Kulp <dk...@apache.org> 1/10/2011 11:46 AM >>>
>
> I'm definitely in support of this as well. I'd actually suggest taking it a
> bit furthur and trying to define some sort of hiearchy of levels and put
> things in more apprioriate places.
>
> For example, it's definitely in the best interest of everything to get most of
> the "api" bundles started up ASAP. Otherwise, you can easily get into
> situations where some bundles use the "system" versions and othere use the
> bundle version and such. Thus, it might be good to say level 20 is for all
> the API jars and 25 for the "impls" or similar, just to make sure the API jars
> are available real early. JAXB and JAX-WS API jars are really affected by
> this pretty badly, especially with the 2.2 versions being a bit incompatible
> with the version in the JDK.
>
> Dan
>
>
> On Monday 10 January 2011 11:01:21 am Kurt Westerfeld wrote:
>> I ran into a similar issue with system bundles being partially started with
>> Apache ODE and related startup issues. It was my suggestion then to start
>> system bundles < 60 and user bundles >60. Would this apply to all bundles
>> that are supplied with features on SMX (like ODE), or just select ones?
>> I'm highly in favor of this, btw.
>>
>> >>> Freeman Fang <fr...@gmail.com> 1/10/2011 4:32 AM >>>
>>
>> Hi,
>>
>> How about we specify start level for camel feature bundles less than
>> 60, so that when restart servicemix, the camel related bundles always
>> get started before end users bundle, this can avoid lots of asyn
>> issues customer may encounter, such as camel component not available
>> yet when end users bundle get started.
>>
>> Actually this discussion initially from fuse forum[1], and I'm not
>> very sure heavily depend on bundle start level is a good practice in
>> OSGi world, but I must admit that in servicemix camel should be
>> considered as a part of the framework, so give higher priority for
>> camel bundles seems OK.
>> Btw, karaf features already support specify start level, so it should
>> be doable in Servicemix to do it.
>>
>> I'd like hear more voice, thoughts?
>>
>> [1]http://fusesource.com/forums/thread.jspa?threadID=2493
>>
>> TIA
>> Freeman
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
Re: [DISCUSS] how about specify camel feature bundle level
less than 60.
Posted by Kurt Westerfeld <kw...@novell.com>.
There is also the case to handle where a "system" bundle is started, and a bundle tracker or something similar does an async start on a separate thread. Witness the extender bundle activation models--lots of threads starting asynchronously.
This all OK, but fast-forward to the situation where something like Camel or ODE is providing infrastructure services that watch for user bundles later. The startup of Camel, I know nothing about, but in ODE's case it's starting a bunch of internal services, all the while the bundle is "started". Now, this may be a bug in the ODE code, but I don't think it's unique. I don't know what the right answer is here but I thought I'd point out that just getting a bundle to "started" state doesn't seem to always be the final answer.
>>> Daniel Kulp <dk...@apache.org> 1/10/2011 11:46 AM >>>
I'm definitely in support of this as well. I'd actually suggest taking it a
bit furthur and trying to define some sort of hiearchy of levels and put
things in more apprioriate places.
For example, it's definitely in the best interest of everything to get most of
the "api" bundles started up ASAP. Otherwise, you can easily get into
situations where some bundles use the "system" versions and othere use the
bundle version and such. Thus, it might be good to say level 20 is for all
the API jars and 25 for the "impls" or similar, just to make sure the API jars
are available real early. JAXB and JAX-WS API jars are really affected by
this pretty badly, especially with the 2.2 versions being a bit incompatible
with the version in the JDK.
Dan
On Monday 10 January 2011 11:01:21 am Kurt Westerfeld wrote:
> I ran into a similar issue with system bundles being partially started with
> Apache ODE and related startup issues. It was my suggestion then to start
> system bundles < 60 and user bundles >60. Would this apply to all bundles
> that are supplied with features on SMX (like ODE), or just select ones?
> I'm highly in favor of this, btw.
>
> >>> Freeman Fang <fr...@gmail.com> 1/10/2011 4:32 AM >>>
>
> Hi,
>
> How about we specify start level for camel feature bundles less than
> 60, so that when restart servicemix, the camel related bundles always
> get started before end users bundle, this can avoid lots of asyn
> issues customer may encounter, such as camel component not available
> yet when end users bundle get started.
>
> Actually this discussion initially from fuse forum[1], and I'm not
> very sure heavily depend on bundle start level is a good practice in
> OSGi world, but I must admit that in servicemix camel should be
> considered as a part of the framework, so give higher priority for
> camel bundles seems OK.
> Btw, karaf features already support specify start level, so it should
> be doable in Servicemix to do it.
>
> I'd like hear more voice, thoughts?
>
> [1]http://fusesource.com/forums/thread.jspa?threadID=2493
>
> TIA
> Freeman
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: [DISCUSS] how about specify camel feature bundle level less than 60.
Posted by Daniel Kulp <dk...@apache.org>.
I'm definitely in support of this as well. I'd actually suggest taking it a
bit furthur and trying to define some sort of hiearchy of levels and put
things in more apprioriate places.
For example, it's definitely in the best interest of everything to get most of
the "api" bundles started up ASAP. Otherwise, you can easily get into
situations where some bundles use the "system" versions and othere use the
bundle version and such. Thus, it might be good to say level 20 is for all
the API jars and 25 for the "impls" or similar, just to make sure the API jars
are available real early. JAXB and JAX-WS API jars are really affected by
this pretty badly, especially with the 2.2 versions being a bit incompatible
with the version in the JDK.
Dan
On Monday 10 January 2011 11:01:21 am Kurt Westerfeld wrote:
> I ran into a similar issue with system bundles being partially started with
> Apache ODE and related startup issues. It was my suggestion then to start
> system bundles < 60 and user bundles >60. Would this apply to all bundles
> that are supplied with features on SMX (like ODE), or just select ones?
> I'm highly in favor of this, btw.
>
> >>> Freeman Fang <fr...@gmail.com> 1/10/2011 4:32 AM >>>
>
> Hi,
>
> How about we specify start level for camel feature bundles less than
> 60, so that when restart servicemix, the camel related bundles always
> get started before end users bundle, this can avoid lots of asyn
> issues customer may encounter, such as camel component not available
> yet when end users bundle get started.
>
> Actually this discussion initially from fuse forum[1], and I'm not
> very sure heavily depend on bundle start level is a good practice in
> OSGi world, but I must admit that in servicemix camel should be
> considered as a part of the framework, so give higher priority for
> camel bundles seems OK.
> Btw, karaf features already support specify start level, so it should
> be doable in Servicemix to do it.
>
> I'd like hear more voice, thoughts?
>
> [1]http://fusesource.com/forums/thread.jspa?threadID=2493
>
> TIA
> Freeman
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: [DISCUSS] how about specify camel feature bundle level
less than 60.
Posted by Kurt Westerfeld <kw...@novell.com>.
I ran into a similar issue with system bundles being partially started with Apache ODE and related startup issues. It was my suggestion then to start system bundles < 60 and user bundles >60. Would this apply to all bundles that are supplied with features on SMX (like ODE), or just select ones? I'm highly in favor of this, btw.
>>> Freeman Fang <fr...@gmail.com> 1/10/2011 4:32 AM >>>
Hi,
How about we specify start level for camel feature bundles less than
60, so that when restart servicemix, the camel related bundles always
get started before end users bundle, this can avoid lots of asyn
issues customer may encounter, such as camel component not available
yet when end users bundle get started.
Actually this discussion initially from fuse forum[1], and I'm not
very sure heavily depend on bundle start level is a good practice in
OSGi world, but I must admit that in servicemix camel should be
considered as a part of the framework, so give higher priority for
camel bundles seems OK.
Btw, karaf features already support specify start level, so it should
be doable in Servicemix to do it.
I'd like hear more voice, thoughts?
[1]http://fusesource.com/forums/thread.jspa?threadID=2493
TIA
Freeman
--
Freeman Fang
------------------------
FuseSource: http://fusesource.com
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang
Apache Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org
Apache Karaf: http://karaf.apache.org
Apache Felix: http://felix.apache.org