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 ) 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
_______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
