On 31/12/2007, Stuart McCulloch <[EMAIL PROTECTED]> wrote: > > On 31/12/2007, David Leangen <[EMAIL PROTECTED]> wrote: > > > > > Thanks for the advice. > > > > More info below... > > > > > Sounds to me you are not giving a proper example. > > > > Probably. > > > > > > > If BundleA only knows of Vehicle, it will only import Vehicle, > > > and if BundleB is then a SkateboardEditor it will know of Skateboard > > > and hence import Skateboard. > > > > Indeed, BundleA only knows of Vehicle and only imports vehicle. Indeed, > > that's all I want it to do. I don't want it to need to know about > > specific > > types of Vehicles, since those should be able to be "plugged into" the > > system without the systems' knowing the specific types in advance. > > > > And yes, SkateboardEditor knows about Skateboards, so it does indeed > > know > > about the Skateboard class (as well as Vehicle, for that matter). > > > > > > > My guess is that you in reality are talking about various > > > systems that take a descriptor of a class, such as a String > > > or a marshalled object of some sort, and that generic > > > system tries to load the class into existence. I am talking > > > about Hibernate, reading Properties files with classnames > > > filled out by third-party, and so forth. > > > > Nope. > > > > Actually, I am simply managing Vehicles and their lifecycle within the > > system. The whole point of the system is to manage Vehicles, so this is > > part > > of my domain model, I guess. > > > > To use your example above, some bundle (BundleS) will register a > > Skateboard > > as a Vehicle to the system, which is tracked by BundleA. BundleA will > > then > > manage the Skateboard just like it would any other Vehicle. BundleS > > should > > not need to do anything regarding management other than registering the > > Skateboard as an OSGi service implementing Vehicle with a property > > "id=skateboard". BundleA, from its perspective, just receives a Vehicle > > that > > it then takes control of as a Vehicle (it doesn't need to know any of > > the > > details of a Skateboard). > > > > Since BundleS knows the specific type, I was wondering how I can pass on > > that type to BundleA at runtime so the service is already casted to the > > specific type. > > > hmm, sounds like you need a service here... > > ie. BundleS could provide a service: "Class findVehicleType(String > vehicleId)" which > BundleA can call to load the relevant class - and if you use the > Whiteboard pattern > from http://www.osgi.org/documents/osgi_technology/whiteboard.pdf then you > might > be able to skip the registration step - as you'd know that vehicle bundles > provide this > service and you can track them via a ServiceTracker > > ( to find which vehicles a bundle knows about you could either provide > another service > or you could use the Extender pattern > http://www.aqute.biz/Snippets/Extender - which > provides another way to track interesting bundles, via Bundle events - > the Spring DM > project uses this approach to find Spring powered bundles ) >
also, just realized - if you track vehicle bundles using the extender pattern then you could always use their classloaders to load the correct types, as you would have the bundle instance from the event: ie. bundle.loadClass(...) or, if you have a well-defined lifecycle then you could delegate certain > actions to other > bundles (for example perhaps get BundleS to actually construct Skateboard > instances?) > > the general idea is to delegate any 'low-level' work (such as > classloading) via services, > which makes your management code more flexible and modular... > > There are many ways to do this in plain old java, but the > > problem is classloading in OSGi, since Skateboard is not imported. I am > > trying to avoid forcing a convention like "must be of class > > com.blah.foo.bar.*" so I can use dynamic imports. I want the choice of > > class > > to be free, which means there's no way of using the dynamic-import in > > the > > manifest. > > > > If it can't be done, it can't be done, but it is a very nice-to-have > > with > > regards to what I'm trying to do: > > > > // The lifecycle management system from BundleA > > Service service = getVehicleService(); > > > > // Registering Skateboard from BundleS > > Skateboard skateboard = new Skateboard(); > > bundleContext.registerService( ... ) //register Skateboard as Vehicle > > > > // Use the registered service from BundleB > > Skateboard skateboard = service.getVehicle( "skateboard" ); > > > > > > Cheers, > > David > > > > _______________________________________________ > > OSGi Developer Mail List > > [email protected] > > http://www2.osgi.org/mailman/listinfo/osgi-dev > > > > > > -- > Cheers, Stuart -- Cheers, Stuart
_______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
