On Friday 12 August 2005 21:07, Vadim Gritsenko wrote: > > whereas Daniel is making a more evolutionary approach > > starting with what OSGi *is*, and continue from there with "solutions to > > use-cases". > > I don't see what usecase it can possibly solve if it does not provide > necessary level of isolation blocks need.
The OSGi specification is fairly exact on many isolation points. Bundles are classloader isolated, and if the bundles play the game according to the specification, then the full isolation needed will be provided. Some of the "need to play along" are; * If you call bundleContext.getService(), i.e. a lookup, you must call the bundleContext.ungetService() when you no longer need it. * If you hold on to a service for long (undefined), you should implement a ServiceListener and call ungetService(), when the service is removed. You should also unget it and get a new reference if the service is modified. The above is essentially a matter of letting go of references to instances, so that the classes can be GCed. The specification is fairly clear that for when a bundle is installed or started, only 2 possible outcomes are allowed; * Successful. * Failure, and the state of the entire platform must be identical to the state prior to attempting the operation. As for multiple versions of the same service; OSGi has covered this in the specification as well. Again, it is fairly important that bundles plays by the rules, and unfortunately one can get away with not playing too well. <quote src="R3 spec" > The Export-Package manifest header allows a bundle to export Java packages to other bundles, exposing the packages to other bundles. The Framework must guarantee that classes and resources in the exported package's name-space are loaded from the exporting bundle. Additionally, the package's classes and resources must be shared among bundles that import the package. See Importing Packages on page 48. If more than one bundle declares the same package in its Export-Package manifest header, the Framework controls the selection of the exporting bundle. The Framework must select for export the bundle offering the highest version of the declared package. </quote> Furthermore; <quote src="R3 spec" > Exporting a package does not imply that the exporting bundle will actually use the classes it offers for export. Multiple bundles can offer to export the same package; the Framework must select only one of those bundles as the exporter. A bundle will implicitly import the same package name and version level as it exports, and therefore a separate Import-Package manifest header for this package is unnecessary. If the bundle can function using a lower specification version of the package than it exports, then the lower version can be specified in an Import-Package manifest header. </quote> This means that exported (i.e. public) packages has a whole set of compatibility requirements attached to them, which IMVHO is a GoodThing. Classes/interfaces that are not part of exported packages (e.g. Eclipse places them in package names "internal") are classloader separated and only a concern within the Bundle. <quote src="R3 spec." > === Recommended Export Strategy === Although a bundle can export all its classes to other bundles, this practice is discouraged except in the case of particularly stable library packages that will need updating only infrequently. The reason for this caution is that the Framework may not be able to promptly reclaim the space occupied by the exported classes if the bundle is updated or uninstalled. Bundle designs that separate interfaces from their implementations are strongly preferred. The bundle developer should put the interfaces into a separate Java package to be exported, while keeping the implementation classes in different packages that are not exported. If the same interface has multiple implementations in multiple bundles, the bundle developer can package the interface package into all of these bundles; the Framework must select one, and only one, of the bundles to export the package, and the interface classes must be loaded from that bundle. Interfaces with the same package and class name should have exactly the same signature. Because a modification to an interface affects all of its callers, interfaces should be carefully designed and remain backward compatible once deployed. </quote> I hope this provides some confidence that "isolation" is the last of Cocoon's worries. :o) OSGi will, however, not provide much help for the "compile blocks" of today to automatically receive any isolation from each other, other than isolation of the entire bundle containing the ECM + its blocks. So, the idea of creating a bundle that wraps "compile blocks" and in that way creates a "real block", is a good idea for migration path. But it should IMHO, not be the primary future recommended pattern. Cheers Niclas
