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: [email protected]
For additional commands, e-mail: [email protected]
