On Thu, Mar 17, 2011 at 3:30 PM, Michael Hess <[email protected]>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.
>
