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.
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.
Furthermore;
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.
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.
=== 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.
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