Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <45633B1E.7010801@nada.kth.se>
Date: Tue, 21 Nov 2006 18:45:02 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Shielded class loading between blocks
References: <ejs2ho$2cj$1@sea.gmane.org> <45618FC0.1070706@apache.org>
 <ejs7kh$irc$1@sea.gmane.org> <4561FBC9.1000408@nada.kth.se>
 <ejv7a5$a1f$1@sea.gmane.org>
In-Reply-To: <ejv7a5$a1f$1@sea.gmane.org>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Alexander Klimetschek skrev:
> Daniel Fagerstrom schrieb:
>> Alexander Klimetschek skrev:
>>> Another requirement what just popped up is to allow "groups" of 
>>> servlets that use the same classloader. This is useful if you have 
>>> some Servlets and jsps that ought to be used together, because the 
>>> multiple Servlets and JSPs access some singleton / static Java 
>>> class. Here it is necessary that all servlets and stuff are loaded 
>>> by the same classloader.
>>
>> Is this really a problem that we need to solve? In most cases using 
>> the common servlet container context classloader or a block servlet 
>> local classloader should be enough. I would need some concrete use 
>> cases to become convinced that it is worth the extra complexity.
>
> Yes, it is. The Solr project for example consists of two Java 
> Servlets, one for storing documents and one for querying documents. 
> Then there is a bunch of jsps to administrate the Solr installation. 
> Both Servlets and jsps make use of static methods of a "SolrCore" 
> class, so they all need the same classloader. The jsps are handled via 
> a sitemap (BTW, I have patched cocoon-jsp to work with BlockServlets, 
> its not yet perfect, so I haven't posted a patch yet).
>
> The need for shielding comes through the dependency for a 
> nightly-built Lucene, which conflicts with another part of our webapp, 
> where an old Lucene is used.
>
> IMHO this might happen any time again and having the flexibility of 
> classloading in Java is perfect for solving those problems. I have 
> implemented that shielded groups stuff in the old 
> BootstrapClassLoaderManager, right now, I am writing on a 
> ShieldingBlockServlet as a proof of concept and to be up-to-date with 
> the cocoon trunk.
OK.

>> IMO it would be useful to have a classloader at the block level and 
>> have some mechanism for importing and exporting packages and services 
>> between the blocks. Fortunately clever people already have put 
>> together a standardized solution for this ;) 
>> http://www.springframework.org/osgi.
>
> How much time will it approximately take to have a stable OSGI 
> implementation in cocoon?
No idea ;)

What needs to be done is:

1. Package the Cocoon blocks as OSGi bundles. There is a Maven plugin 
developed by the Felix community that makes this fairly easy. But one 
important complication is that OSGi class sharing is package based and 
only one bundle can contribute a specific package. That means that we 
have to reorganize the use of packages for some blocks (e.g. 
o.a.c.transformation have components in several blocks).

2. All external dependencies must either be bundles or included in our 
bundles. This is more complicated. Including dependencies in our bundles 
is clumsy and packaging everything external is a huge work. Fortunately 
there are work on this in other communities. Felix, Eclipse and the OSGi 
organization are creating repositories with "bundelized" common jars. 
Felix have also done some work on making it really easy to bundelize a 
jar with a maven plugin. Maven are also working together with Felix to 
make the jar plugin create a default Felix manifest.

3. The Spring configurations in the blocks needs to be extended with 
special Spring-OSGi elements that describe what services (components) 
that each block exposes and depends on.

4. We have to put all this in a OSGi container that is embeddable as a 
webapp. Eclipse have developed a such, so this would hopefully not be 
that difficult.

I would say that point 2, is the critical point.

/Daniel