Just listen for RESOLVED and STARTED events. On RESOLVED, you can check whether the newly resolved bundle is fragment and whether its host is ACTIVE. In case it is not ACTIVE, then add the host bundle to a list. On STARTED event, you check whether the list with waiting host bundles with attached fragments contains the just STARTED bundle. This way you will cover both attachment policies of the fragments and you doesn't need to spawn new threads.
BR, -- Danail Nachev Senior Software Engineer/Development Tools ProSyst Labs EOOD ------------------------------------------------- stay in touch with your product. ------------------------------------------------- Mirko Jahn wrote: > Well, plain simple these are l10n resources. In order to access them > from the bundle, they have to be in the class path of that bundle. > Unfortunately import statements don't fit here, because we can have > multiple bundles with the same package - a classic split package > problem. The service part, I am working on, is just a small fraction > of the actual problem domain (adding some degree of flexibility). In > our core we are relying on standard Spring APIs like > "ResourceBundleMessageSource" f.i.. > > So, to answer your question, using plug-ins wouldn't make it easier - > neither for us developing it, nor the ones later using it as a > development platform - unfortunately. > > Thanks, > Mirko > -- > Mirko Jahn > e-mail: [email protected] > blog: http://osgi.mjahn.net > > On Wed, Feb 4, 2009 at 7:58 AM, Peter Kriens <[email protected]> wrote: >> I am not sure why you go to the pain of fragments instead of using normal >> bundles? >> >> Kind regards, >> >> Peter Kriens >> >> On 4 feb 2009, at 01:03, Mirko Jahn wrote: >> >>> 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 >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
