Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
From: Niclas Hedhman <niclas@hedhman.org>
To: dev@cocoon.apache.org
Subject: Re: [RT] The impact of using OSGi
Date: Fri, 12 Aug 2005 22:02:27 +0800
User-Agent: KMail/1.7.2
References: <42E4976F.30702@apache.org>
 <200508121720.55355.niclas@hedhman.org> <42FC9F06.8020608@reverycodes.com>
In-Reply-To: <42FC9F06.8020608@reverycodes.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200508122202.27110.niclas@hedhman.org>

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