Thanks Danail, great hint! The pattern for the case I was missing helped me here. The "regular case" I've already covered, so the only thing I have to check is, if a fragment triggers a RESOLVED and its host is ACTIVE. In this case I check if the fragments is from the kind I am looking for and potentially register the service. So I don't even need this list. Synchronization shouldn't be an issue (like within Spring, when every bundles gets started in a different thread asynchronously), because if the fragment is RESOLVED and the host is not ACTIVE, the started event will trigger the regular check/registration process when the host gets started. Thanks again, that was the hint I was looking for! How could I have missed that... so simple - it was a 4 liner to fix :-).
Cheers, Mirko On Thu, Feb 5, 2009 at 9:33 AM, Danail Nachev <[email protected]> wrote: > 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 > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
