Hi folks,
while working on an extender to detect special fragments in the osgi
container, I came across some problems handling events and would
like
to hear what you think about it. Here is what I am trying to
accomplish...
My requirements are the following. I am not assuming any
installation
order or any fixed set of bundles. Everything is fully dynamic. In
my
container, I have certain bundles providing my core functionality,
which can be "extended" with fragments (basically l10n resources).
For
each fragment attached to a host, I register a (or more)service(s)
(special spring bean class) for the host indicating that these
resources are available. Now, to remove the developer from handling
the service registration, I have to provide an extender taking
care of
this. So far so good.
My first naive approach was look at the life cycle of fragments
described in section 3.14 in the OSGi R4.1 core spec. It states that
once a potential host bundle is started in order to attach a
fragment
the host has to be stopped and resolved again with the resolved
fragment. I basically implemented a SynchronizedBundleListener to
get
notified about "started" events, assuming all available fragments
are
attached and when new fragments get attached, the framework notifies
me again, everytime a new fragment gets attached (new "started"
event). Unfortunately this didn't work out so well. When a fragment
comes later as the host bundle in the start order the framework
doesn't restart the host. First I thought this is a bug, but then I
learned about section 3.5.2 where the "Bundle-SymbolicName" header
is
discussed. There the "behavior" of attaching fragments is completely
changed by defining: "Bundle-SymbolicName:
foo.bar;fragment-attachment:always". The spec states: "Fragments can
attach at any time while the host is resolved or during the
process of
resolving" meaning (my interpretation) no BundleEvents from the host
bundle about this event. Worst thing about this, besides not being
referenced in the Fragment section (really hard to find!!) is that
there is no default value or switch you can set to define your own
default behavior.
Well, of course there is a way around. Instead of listening to the
host, one can just listen to fragments being attached to a host - no
problem with this. Well, the only problem here is that I am trying
to
register a service. If the host is not started, I can't use the
BundleContext of the host to register the service(s) - at least not
immediately. I can spawn a thread waiting for the bundle to get
started and then register the fragment. I can even start the
bundle in
order to get the BundleContext and then register the service (in a
thread). The problem is just that maybe the bundle was stopped on
purpose to disable a certain functionality or starting all bundles
would be to resource intensitiv so doing this automatically might
not
be such a good idea with a couple hundred (or maybe even thousand
bundles). Besides, potentially spawning many threads can also be a
problem, so you might wonna think about some manager taking care of
this as well. I could continue like this further, but I think your
getting the point. Not being able to receive anything from the host
bundles point of view makes working with fragments kinda messy.
Now my question(s). Did I miss anything that can make my life a lot
easier or is it just like that? Are there any efforts to support
something like a "FragmentAttachedEvent"? Will the upcoming
BundleTracker sport some sort of support for such kind of use cases
except the mechanisms described in the 2nd version of the spec
draft?
puh, so many questions ;-) Sorry for the lengthy post.
Cheers,
Mirko
--
Mirko Jahn
e-mail: [email protected]
blog: http://osgi.mjahn.net
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
