You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by stream <st...@gmail.com> on 2011/03/15 10:36:20 UTC
About the startlevel
Hi,
i am navie. i wanna ask a question about startlevel.
is it important that set the startlevel, i mean what will happen if all bundle on the same level.
thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: About the startlevel
Posted by Per-Erik Svensson <pe...@gmail.com>.
On Thu, Mar 17, 2011 at 3:30 PM, Michael Hess <MH...@orga-systems.com>wrote:
> > >> Hi,
> > > Hi,
> > >
> > >> i am navie. i wanna ask a question about startlevel.
> > >> is it important that set the startlevel, i mean what will happen if
> all
> > > > bundle on the same level.
> >
> > Typically, this is not an issue. There are only a handful of reasons why
>
> > you should worry about the start level. In general, it is the normal
> > situation that all bundles have the same start level.
>
> I'd better not show you our bundle startup sequence, then ... ;-)
>
> > > You don't get any guarantee about the sequence in which bundles are
> > > started then.
> >
> > I think the spec says something about ordering withing a start level
> > too, but this is irrelevant really since you shouldn't depend on
> ordering.
>
> Yes, absolutely. I should find some time to check out the spec concerning
> the ordering inside the level. I wonder which information is used to
> define the sequence.
>
> > > If you need some package to be exported before hand, you MUST assure
> that
> > > the exporting bundle is started before the importing one. This can be
> > > assured by proper startlevels.
> >
> > You do not need start levels at all for package sharing. In fact, the
> > resolver completely ignores start levels and will automatically handle
> > package dependencies irrespective of the start level. In other words, a
> > bundle can share packages even if it isn't started and/or its start
> > level isn't met.
>
> Interesting. But in a way it makes sense, because a passive bundle that is
> not started still can provide exports.
>
> > > This could (not must!) be a problem if your bundles rely on the
> presence
> > > of a specific service when they start. If you build your software, so
> that
> > > it is capable of coping with services to appear later on (i.e. after
> they
> > > have already started), then it will not matter that much. Otherwise
> you
> > > will want to assure that the service is there before you access it.
> >
> > Rely on service dependency management, not ordering. Code that relies on
>
> > ordering should be considered broken.
>
> Well, since bundles are started in a serial fashion (or not???), ignoring
> the sequence will force you to have some kind of support for late
> registration of services. I have built something like this with the help
> of the ServiceTrackerCustomizers, and it works. But it is still more
> complicated then simply creating a ServiceTracker, opening it, and
> retrieving the service.
> I understand your point there, and I think you are right from a
> theoretical perspective. But as I outlined further below, I think it
> really is not all black and white in that area.
>
> For example logging - which probably is a central service in every
> application. Would you really write code, that everytime it accesses the
> log service it first checks for the presence of the service by retrieving
> it from a ServiceTracker?
I believe the "right" way to do it is to use any of the component frameworks
to inject your dependencies. If you need a logger you simply tell the
component framework to not start your component unless there is a logger and
stop it if the logger disappears. If you can get by without a logger (wich
arguably you can) you "simply" make your component switch between an
injected logger and a hand-built NoLoggerAvailableLogger when the log
service becomes unavailable. Thus, all classes in your bundle, except the
component, would always have a logger, sometimes a framework injected
logger, and sometimes a bare-bones hand crafted logger. This would also make
your "internal" classes less tied to OSGi.
> Though, as far as I know this is the "right way
> to do it", I would still say it feels like I am "overdoing" it here.
> In my current application, I simply expect logging to be a "core" service,
> which is simply not allowed to disappear.
If you have a service that you want to be part of the "core", you might want
to start that service together with the framework.
However, this is really not a problem to be solved by starting levels. You
either have a "hard" dependency on a service or a "soft" or none at all.
With hard, I mean that you can't get by without it. With soft, I mean that
you can use the service, but it isn't a must have. You shouldn't be
registering your service unless your hard dependencies are available, and
you should unregister your services when your hard dependencies goes away.
If you solve this with start levels, don't you ever get the problem that
different services in your bundle have different kinds ("hard", "soft") of
dependencies on different kind of services?
All this gets alot easier when you use a component framework such as DS.
> Hence my strategy is simple: I
> get a reference to the service in the activator of my bundles, and then I
> reuse it everywhere in that bundle.
>
> I think this also puts up the qestion of what the implacation of such a
> disappearing service would be from a business point of view. While the
> software could certainly work without logging (by work I mean, service the
> business case), it would still mean I am blindfolded when it comes to
> problems. So coming from that perspective I would say - once the logging
> is gone, the system is broken and should not commence working simply
> because I cannot tell anymore whether the system is out of control or not.
>
>
Then you need a logger, it is a dependency you can't live without. That has
got nothing to do with start levels. Rather, it has to do with you stopping
your own services when the logger goes away and not starting your service
until the logger is available.
> > > But keep in mind, that by doing so you essentially undermine the
> dynamic
> > > nature of the OSGi system. Though the consumed service might be there
> when
> > > your bundle starts, the service could nevertheless disappear later on.
> So
> > > it also depends on how much "control" you have over the overall
> runtime.
> > > If you build a closed source product, where everything is under your
> > > control, you can of course put rules into place, that specific
> situations
> > > are simply not supported. This means, that though you cannot prevent
> the
> > > afforementioned service to disappear technically, you can still define
> > > that it is not permitted to remove the service.
> >
> > Yes, all of this depends on the given situation and what you can do
> > about it.
>
> You're right. This is in fact something I missed very much when I first
> started with OSGI. You can find technically detailed answers, but
> best-practices or inspiring documents for the "depends on ..." moments are
> rare to come by. At least, that's my perception.
>
> > > Though this might at first seem a bit like "cheating", I can tell from
> > > first hand experience, that when it comes to parts of a running(!)
> system
> > > to disappear, things WILL get tricky. So I think it is always a good
> > > choice to check what you gain by this degree a flexibility in contrast
> to
> > > the additional efforts in implementation and complexity.
> > >
> > > But back to the main topic: I think, that usually you will have some
> kind
> > > of sequence, that simply "makes sense". So use the startlevels to
> achieve
> > > this sequence. That's at least how I tend to do it. And it works out
> fine
> > > so far.
> >
> > Still, I'd recommend completely ignoring start levels unless you run
> > into some misbehaving bundle that requires otherwise.
>
> I will take it into consideration.
>
> Thanks for your view on this, Richard.
>
> bye, Michael
>
My take on start levels is quite simple: Only use when a certain bundle need
to be started before other bundles because the former implicitly affects the
service registrations of the latter. I can't think of good reasons to change
the start level except when you install bundles such as declarative services
or a bundle that deals with service hooks. A logger is either needed or
wanted, but it does not affect what services you see or how you get a hold
of the services. Therefore it shouldn't have any other start level than what
the framework defaults it to. At least that's my opinion.
>
> The information included in this e-mail and any files transmitted with it
> is strictly confidential and may be privileged or otherwise protected from
> disclosure. If you are not the intended recipient, please notify the sender
> immediately by e-mail and delete this e-mail as well as any attachment from
> your system. If you are not the intended recipient you are not authorized to
> use and/or copy this message and/or attachment and/or disclose the contents
> to any other person.
>
Re: About the startlevel
Posted by Michael Hess <MH...@orga-systems.com>.
> >>>> Rely on service dependency management, not ordering. Code that
relies
> > on
> >>>> ordering should be considered broken.
> >>> Well, since bundles are started in a serial fashion (or not???),
> > ignoring
> >>> the sequence will force you to have some kind of support for late
> >>> registration of services. I have built something like this with the
> > help
> >>> of the ServiceTrackerCustomizers, and it works. But it is still more
> >>> complicated then simply creating a ServiceTracker, opening it, and
> >>> retrieving the service.
> >>> I understand your point there, and I think you are right from a
> >>> theoretical perspective. But as I outlined further below, I think it
> >>> really is not all black and white in that area.
> >> If you are responding to service events, then ordering is generally
not
> >> an issue. This is simplified even more if you use something like
iPOJO,
> >> DS, etc. since your component won't even be created until its
> >> dependencies are satisfied, which then is basically the same as your
> >> "creating a ServiceTracker, opening it, and retrieving the service"
> >> approach. You can do the same manually with service listeners, but
why
> >> bother when these component frameworks will do it for you?
> > Why do I suddenly feel like I am missing out on something big here...
> > Are you basically telling me I can do IOC style things out of the box
by
> > using DS (or iPOJO)?
>
> I am not sure what you mean by "out of the box"...but
> DS/iPOJO/Dependency Manager/etc. all support an IoC approach to OSGi
> programming...the exact details of each is different, but they all
> interoperate via services and the service registry.
OK, I think I have some "homework" todo. Seems like there are solutions to
some of the problems we are fighting.
> >>> For example logging - which probably is a central service in every
> >>> application. Would you really write code, that everytime it accesses
> > the
> >>> log service it first checks for the presence of the service by
> > retrieving
> >>> it from a ServiceTracker? Though, as far as I know this is the
"right
> > way
> >>> to do it", I would still say it feels like I am "overdoing" it here.
> >>> In my current application, I simply expect logging to be a "core"
> > service,
> >>> which is simply not allowed to disappear. Hence my strategy is
simple:
> > I
> >>> get a reference to the service in the activator of my bundles, and
> > then I
> >>> reuse it everywhere in that bundle.
> >> No, I wouldn't do that for logging. I'd use iPOJO to declare the log
> >> service as an optional dependency and have it inject me with the
service
> >> if it exist or a null object if it doesn't and I'd just ignore the
> >> situation completely.
> > OK, understood. But how do you manage the possible null pointer behind
> > your log references? Is there some other trick one can pull off, to
> > prevent permanent writing of tedious null checks?
>
> In iPOJO, for example, you can have it inject your components with a
> "null object" if an optional service is not available. The "null object"
> is just a dummy implementation that does nothing. You can also specify
> your own custom dummy object that does whatever you want.
Yummy, this sounds good. Need to check it (especially because I have iPOJO
in here already for something...)
Thank you so much for your input!
Michael
> -> richard
>
> >
> >>> I think this also puts up the qestion of what the implacation of
such
> > a
> >>> disappearing service would be from a business point of view. While
the
> >>> software could certainly work without logging (by work I mean,
service
> > the
> >>> business case), it would still mean I am blindfolded when it comes
to
> >>> problems. So coming from that perspective I would say - once the
> > logging
> >>> is gone, the system is broken and should not commence working simply
> >>> because I cannot tell anymore whether the system is out of control
or
> > not.
> >> For mandatory services, I'd just tell iPOJO it was a mandatory
> >> dependency and it would tear things down for me in case of a failure.
> >> Not much else you can do if a required service goes away.
> > Point taken!
> >
> > Michael
> >
> > The information included in this e-mail and any files transmitted with
it is strictly
> confidential and may be privileged or otherwise protected from
disclosure. If you are not the
> intended recipient, please notify the sender immediately by e-mail and
delete this e-mail as well
> as any attachment from your system. If you are not the intended
recipient you are not authorized
> to use and/or copy this message and/or attachment and/or disclose the
contents to any other person.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
The information included in this e-mail and any files transmitted with it is strictly confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this e-mail as well as any attachment from your system. If you are not the intended recipient you are not authorized to use and/or copy this message and/or attachment and/or disclose the contents to any other person.
Re: About the startlevel
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 3/17/11 12:57, Michael Hess wrote:
>>>> Rely on service dependency management, not ordering. Code that relies
> on
>>>> ordering should be considered broken.
>>> Well, since bundles are started in a serial fashion (or not???),
> ignoring
>>> the sequence will force you to have some kind of support for late
>>> registration of services. I have built something like this with the
> help
>>> of the ServiceTrackerCustomizers, and it works. But it is still more
>>> complicated then simply creating a ServiceTracker, opening it, and
>>> retrieving the service.
>>> I understand your point there, and I think you are right from a
>>> theoretical perspective. But as I outlined further below, I think it
>>> really is not all black and white in that area.
>> If you are responding to service events, then ordering is generally not
>> an issue. This is simplified even more if you use something like iPOJO,
>> DS, etc. since your component won't even be created until its
>> dependencies are satisfied, which then is basically the same as your
>> "creating a ServiceTracker, opening it, and retrieving the service"
>> approach. You can do the same manually with service listeners, but why
>> bother when these component frameworks will do it for you?
> Why do I suddenly feel like I am missing out on something big here...
> Are you basically telling me I can do IOC style things out of the box by
> using DS (or iPOJO)?
I am not sure what you mean by "out of the box"...but
DS/iPOJO/Dependency Manager/etc. all support an IoC approach to OSGi
programming...the exact details of each is different, but they all
interoperate via services and the service registry.
>
>>> For example logging - which probably is a central service in every
>>> application. Would you really write code, that everytime it accesses
> the
>>> log service it first checks for the presence of the service by
> retrieving
>>> it from a ServiceTracker? Though, as far as I know this is the "right
> way
>>> to do it", I would still say it feels like I am "overdoing" it here.
>>> In my current application, I simply expect logging to be a "core"
> service,
>>> which is simply not allowed to disappear. Hence my strategy is simple:
> I
>>> get a reference to the service in the activator of my bundles, and
> then I
>>> reuse it everywhere in that bundle.
>> No, I wouldn't do that for logging. I'd use iPOJO to declare the log
>> service as an optional dependency and have it inject me with the service
>> if it exist or a null object if it doesn't and I'd just ignore the
>> situation completely.
> OK, understood. But how do you manage the possible null pointer behind
> your log references? Is there some other trick one can pull off, to
> prevent permanent writing of tedious null checks?
In iPOJO, for example, you can have it inject your components with a
"null object" if an optional service is not available. The "null object"
is just a dummy implementation that does nothing. You can also specify
your own custom dummy object that does whatever you want.
-> richard
>
>>> I think this also puts up the qestion of what the implacation of such
> a
>>> disappearing service would be from a business point of view. While the
>>> software could certainly work without logging (by work I mean, service
> the
>>> business case), it would still mean I am blindfolded when it comes to
>>> problems. So coming from that perspective I would say - once the
> logging
>>> is gone, the system is broken and should not commence working simply
>>> because I cannot tell anymore whether the system is out of control or
> not.
>> For mandatory services, I'd just tell iPOJO it was a mandatory
>> dependency and it would tear things down for me in case of a failure.
>> Not much else you can do if a required service goes away.
> Point taken!
>
> Michael
>
> The information included in this e-mail and any files transmitted with it is strictly confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this e-mail as well as any attachment from your system. If you are not the intended recipient you are not authorized to use and/or copy this message and/or attachment and/or disclose the contents to any other person.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: About the startlevel
Posted by Michael Hess <MH...@orga-systems.com>.
> >> Rely on service dependency management, not ordering. Code that relies
on
> >> ordering should be considered broken.
> > Well, since bundles are started in a serial fashion (or not???),
ignoring
> > the sequence will force you to have some kind of support for late
> > registration of services. I have built something like this with the
help
> > of the ServiceTrackerCustomizers, and it works. But it is still more
> > complicated then simply creating a ServiceTracker, opening it, and
> > retrieving the service.
> > I understand your point there, and I think you are right from a
> > theoretical perspective. But as I outlined further below, I think it
> > really is not all black and white in that area.
>
> If you are responding to service events, then ordering is generally not
> an issue. This is simplified even more if you use something like iPOJO,
> DS, etc. since your component won't even be created until its
> dependencies are satisfied, which then is basically the same as your
> "creating a ServiceTracker, opening it, and retrieving the service"
> approach. You can do the same manually with service listeners, but why
> bother when these component frameworks will do it for you?
Why do I suddenly feel like I am missing out on something big here...
Are you basically telling me I can do IOC style things out of the box by
using DS (or iPOJO)?
> > For example logging - which probably is a central service in every
> > application. Would you really write code, that everytime it accesses
the
> > log service it first checks for the presence of the service by
retrieving
> > it from a ServiceTracker? Though, as far as I know this is the "right
way
> > to do it", I would still say it feels like I am "overdoing" it here.
> > In my current application, I simply expect logging to be a "core"
service,
> > which is simply not allowed to disappear. Hence my strategy is simple:
I
> > get a reference to the service in the activator of my bundles, and
then I
> > reuse it everywhere in that bundle.
>
> No, I wouldn't do that for logging. I'd use iPOJO to declare the log
> service as an optional dependency and have it inject me with the service
> if it exist or a null object if it doesn't and I'd just ignore the
> situation completely.
OK, understood. But how do you manage the possible null pointer behind
your log references? Is there some other trick one can pull off, to
prevent permanent writing of tedious null checks?
> > I think this also puts up the qestion of what the implacation of such
a
> > disappearing service would be from a business point of view. While the
> > software could certainly work without logging (by work I mean, service
the
> > business case), it would still mean I am blindfolded when it comes to
> > problems. So coming from that perspective I would say - once the
logging
> > is gone, the system is broken and should not commence working simply
> > because I cannot tell anymore whether the system is out of control or
not.
>
> For mandatory services, I'd just tell iPOJO it was a mandatory
> dependency and it would tear things down for me in case of a failure.
> Not much else you can do if a required service goes away.
Point taken!
Michael
The information included in this e-mail and any files transmitted with it is strictly confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this e-mail as well as any attachment from your system. If you are not the intended recipient you are not authorized to use and/or copy this message and/or attachment and/or disclose the contents to any other person.
Re: About the startlevel
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 3/17/11 10:30, Michael Hess wrote:
>
>> Rely on service dependency management, not ordering. Code that relies on
>> ordering should be considered broken.
> Well, since bundles are started in a serial fashion (or not???), ignoring
> the sequence will force you to have some kind of support for late
> registration of services. I have built something like this with the help
> of the ServiceTrackerCustomizers, and it works. But it is still more
> complicated then simply creating a ServiceTracker, opening it, and
> retrieving the service.
> I understand your point there, and I think you are right from a
> theoretical perspective. But as I outlined further below, I think it
> really is not all black and white in that area.
If you are responding to service events, then ordering is generally not
an issue. This is simplified even more if you use something like iPOJO,
DS, etc. since your component won't even be created until its
dependencies are satisfied, which then is basically the same as your
"creating a ServiceTracker, opening it, and retrieving the service"
approach. You can do the same manually with service listeners, but why
bother when these component frameworks will do it for you?
> For example logging - which probably is a central service in every
> application. Would you really write code, that everytime it accesses the
> log service it first checks for the presence of the service by retrieving
> it from a ServiceTracker? Though, as far as I know this is the "right way
> to do it", I would still say it feels like I am "overdoing" it here.
> In my current application, I simply expect logging to be a "core" service,
> which is simply not allowed to disappear. Hence my strategy is simple: I
> get a reference to the service in the activator of my bundles, and then I
> reuse it everywhere in that bundle.
No, I wouldn't do that for logging. I'd use iPOJO to declare the log
service as an optional dependency and have it inject me with the service
if it exist or a null object if it doesn't and I'd just ignore the
situation completely.
> I think this also puts up the qestion of what the implacation of such a
> disappearing service would be from a business point of view. While the
> software could certainly work without logging (by work I mean, service the
> business case), it would still mean I am blindfolded when it comes to
> problems. So coming from that perspective I would say - once the logging
> is gone, the system is broken and should not commence working simply
> because I cannot tell anymore whether the system is out of control or not.
For mandatory services, I'd just tell iPOJO it was a mandatory
dependency and it would tear things down for me in case of a failure.
Not much else you can do if a required service goes away.
-> richard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: About the startlevel
Posted by Michael Hess <MH...@orga-systems.com>.
> >> Hi,
> > Hi,
> >
> >> i am navie. i wanna ask a question about startlevel.
> >> is it important that set the startlevel, i mean what will happen if
all
> > > bundle on the same level.
>
> Typically, this is not an issue. There are only a handful of reasons why
> you should worry about the start level. In general, it is the normal
> situation that all bundles have the same start level.
I'd better not show you our bundle startup sequence, then ... ;-)
> > You don't get any guarantee about the sequence in which bundles are
> > started then.
>
> I think the spec says something about ordering withing a start level
> too, but this is irrelevant really since you shouldn't depend on
ordering.
Yes, absolutely. I should find some time to check out the spec concerning
the ordering inside the level. I wonder which information is used to
define the sequence.
> > If you need some package to be exported before hand, you MUST assure
that
> > the exporting bundle is started before the importing one. This can be
> > assured by proper startlevels.
>
> You do not need start levels at all for package sharing. In fact, the
> resolver completely ignores start levels and will automatically handle
> package dependencies irrespective of the start level. In other words, a
> bundle can share packages even if it isn't started and/or its start
> level isn't met.
Interesting. But in a way it makes sense, because a passive bundle that is
not started still can provide exports.
> > This could (not must!) be a problem if your bundles rely on the
presence
> > of a specific service when they start. If you build your software, so
that
> > it is capable of coping with services to appear later on (i.e. after
they
> > have already started), then it will not matter that much. Otherwise
you
> > will want to assure that the service is there before you access it.
>
> Rely on service dependency management, not ordering. Code that relies on
> ordering should be considered broken.
Well, since bundles are started in a serial fashion (or not???), ignoring
the sequence will force you to have some kind of support for late
registration of services. I have built something like this with the help
of the ServiceTrackerCustomizers, and it works. But it is still more
complicated then simply creating a ServiceTracker, opening it, and
retrieving the service.
I understand your point there, and I think you are right from a
theoretical perspective. But as I outlined further below, I think it
really is not all black and white in that area.
For example logging - which probably is a central service in every
application. Would you really write code, that everytime it accesses the
log service it first checks for the presence of the service by retrieving
it from a ServiceTracker? Though, as far as I know this is the "right way
to do it", I would still say it feels like I am "overdoing" it here.
In my current application, I simply expect logging to be a "core" service,
which is simply not allowed to disappear. Hence my strategy is simple: I
get a reference to the service in the activator of my bundles, and then I
reuse it everywhere in that bundle.
I think this also puts up the qestion of what the implacation of such a
disappearing service would be from a business point of view. While the
software could certainly work without logging (by work I mean, service the
business case), it would still mean I am blindfolded when it comes to
problems. So coming from that perspective I would say - once the logging
is gone, the system is broken and should not commence working simply
because I cannot tell anymore whether the system is out of control or not.
> > But keep in mind, that by doing so you essentially undermine the
dynamic
> > nature of the OSGi system. Though the consumed service might be there
when
> > your bundle starts, the service could nevertheless disappear later on.
So
> > it also depends on how much "control" you have over the overall
runtime.
> > If you build a closed source product, where everything is under your
> > control, you can of course put rules into place, that specific
situations
> > are simply not supported. This means, that though you cannot prevent
the
> > afforementioned service to disappear technically, you can still define
> > that it is not permitted to remove the service.
>
> Yes, all of this depends on the given situation and what you can do
> about it.
You're right. This is in fact something I missed very much when I first
started with OSGI. You can find technically detailed answers, but
best-practices or inspiring documents for the "depends on ..." moments are
rare to come by. At least, that's my perception.
> > Though this might at first seem a bit like "cheating", I can tell from
> > first hand experience, that when it comes to parts of a running(!)
system
> > to disappear, things WILL get tricky. So I think it is always a good
> > choice to check what you gain by this degree a flexibility in contrast
to
> > the additional efforts in implementation and complexity.
> >
> > But back to the main topic: I think, that usually you will have some
kind
> > of sequence, that simply "makes sense". So use the startlevels to
achieve
> > this sequence. That's at least how I tend to do it. And it works out
fine
> > so far.
>
> Still, I'd recommend completely ignoring start levels unless you run
> into some misbehaving bundle that requires otherwise.
I will take it into consideration.
Thanks for your view on this, Richard.
bye, Michael
The information included in this e-mail and any files transmitted with it is strictly confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this e-mail as well as any attachment from your system. If you are not the intended recipient you are not authorized to use and/or copy this message and/or attachment and/or disclose the contents to any other person.
RE: About the startlevel
Posted by Larry Touve <lt...@potomacfusion.com>.
Let me throw in my 2 cents about the StartLevel subject.
I was originally of the impression that I needed to explicitly control the start order of our bundles. We have about 25 bundles that all depend on 2 core bundles. Some of the bundles' services interact with other bundles' services. Our primary (core) bundles implement BundleListener and ServiceListener and all the bundles utilize ServiceTrackers for getting at one another's services. We initially encountered some problems, but it turned out that it wasn't due to the start order of the bundles, it was due to our use of ConfigurationAdmin.
As Richard points out, all of the dependencies are handled quite nicely by the framework. We deploy our bundles by copying them into the autodeploy/bundles area (we're using GlassFish). When we start from scratch, we can drop all 25+ bundles in at once and all of the bundles will start up and resolve properly. If you try to access other services from within your BundleActivator classes, then you may encounter some contention issues. We have noticed, however, that once the bundles are started up, they retain that particular start order on framework restarts until the OSGI cache is cleared out.
The one area where we did encounter problems is the use of Configurations. We have a couple of config files that we put into autodeploy/bundles that we access using the ConfigurationAdmin mechanism. These do not seem to follow any particular start order. In fact, most of the time the Configurations seem to get created after all of the bundles are resolved. When we try to access those from the BundleActivator, then there may be times when the Configuration is not available.
Larry Touve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: About the startlevel
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 3/15/11 7:09, Michael Hess wrote:
>> Hi,
> Hi,
>
>> i am navie. i wanna ask a question about startlevel.
>> is it important that set the startlevel, i mean what will happen if all
> > bundle on the same level.
Typically, this is not an issue. There are only a handful of reasons why
you should worry about the start level. In general, it is the normal
situation that all bundles have the same start level.
> You don't get any guarantee about the sequence in which bundles are
> started then.
I think the spec says something about ordering withing a start level
too, but this is irrelevant really since you shouldn't depend on ordering.
> If you need some package to be exported before hand, you MUST assure that
> the exporting bundle is started before the importing one. This can be
> assured by proper startlevels.
You do not need start levels at all for package sharing. In fact, the
resolver completely ignores start levels and will automatically handle
package dependencies irrespective of the start level. In other words, a
bundle can share packages even if it isn't started and/or its start
level isn't met.
> This could (not must!) be a problem if your bundles rely on the presence
> of a specific service when they start. If you build your software, so that
> it is capable of coping with services to appear later on (i.e. after they
> have already started), then it will not matter that much. Otherwise you
> will want to assure that the service is there before you access it.
Rely on service dependency management, not ordering. Code that relies on
ordering should be considered broken.
> But keep in mind, that by doing so you essentially undermine the dynamic
> nature of the OSGi system. Though the consumed service might be there when
> your bundle starts, the service could nevertheless disappear later on. So
> it also depends on how much "control" you have over the overall runtime.
> If you build a closed source product, where everything is under your
> control, you can of course put rules into place, that specific situations
> are simply not supported. This means, that though you cannot prevent the
> afforementioned service to disappear technically, you can still define
> that it is not permitted to remove the service.
Yes, all of this depends on the given situation and what you can do
about it.
> Though this might at first seem a bit like "cheating", I can tell from
> first hand experience, that when it comes to parts of a running(!) system
> to disappear, things WILL get tricky. So I think it is always a good
> choice to check what you gain by this degree a flexibility in contrast to
> the additional efforts in implementation and complexity.
>
> But back to the main topic: I think, that usually you will have some kind
> of sequence, that simply "makes sense". So use the startlevels to achieve
> this sequence. That's at least how I tend to do it. And it works out fine
> so far.
Still, I'd recommend completely ignoring start levels unless you run
into some misbehaving bundle that requires otherwise.
-> richard
> bye,
> Michael
>
>
> The information included in this e-mail and any files transmitted with it is strictly confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this e-mail as well as any attachment from your system. If you are not the intended recipient you are not authorized to use and/or copy this message and/or attachment and/or disclose the contents to any other person.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: About the startlevel
Posted by Michael Hess <MH...@orga-systems.com>.
> Hi,
Hi,
> i am navie. i wanna ask a question about startlevel.
> is it important that set the startlevel, i mean what will happen if all
bundle on the same level.
You don't get any guarantee about the sequence in which bundles are
started then.
If you need some package to be exported before hand, you MUST assure that
the exporting bundle is started before the importing one. This can be
assured by proper startlevels.
This could (not must!) be a problem if your bundles rely on the presence
of a specific service when they start. If you build your software, so that
it is capable of coping with services to appear later on (i.e. after they
have already started), then it will not matter that much. Otherwise you
will want to assure that the service is there before you access it.
But keep in mind, that by doing so you essentially undermine the dynamic
nature of the OSGi system. Though the consumed service might be there when
your bundle starts, the service could nevertheless disappear later on. So
it also depends on how much "control" you have over the overall runtime.
If you build a closed source product, where everything is under your
control, you can of course put rules into place, that specific situations
are simply not supported. This means, that though you cannot prevent the
afforementioned service to disappear technically, you can still define
that it is not permitted to remove the service.
Though this might at first seem a bit like "cheating", I can tell from
first hand experience, that when it comes to parts of a running(!) system
to disappear, things WILL get tricky. So I think it is always a good
choice to check what you gain by this degree a flexibility in contrast to
the additional efforts in implementation and complexity.
But back to the main topic: I think, that usually you will have some kind
of sequence, that simply "makes sense". So use the startlevels to achieve
this sequence. That's at least how I tend to do it. And it works out fine
so far.
bye,
Michael
The information included in this e-mail and any files transmitted with it is strictly confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this e-mail as well as any attachment from your system. If you are not the intended recipient you are not authorized to use and/or copy this message and/or attachment and/or disclose the contents to any other person.