Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <47FB5D07.3030703@apache.org>
Date: Tue, 08 Apr 2008 13:54:47 +0200
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: "dev@cocoon.apache.org" <dev@cocoon.apache.org>
Subject: JNet integration
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit


At the ApacheCon Carsten, Grek and I had the chance to talk about the JNet
integration and to find a solution that (hopefully) works.

* First we all believe that it is not a good idea to consider the blockcontext:/
   URLs as expressions that are resolved to file: URLs. We want to make them
   real URLs.

* Taking care of URL handling is NOT the responsiblity the Servlet-Service
   framework.

* The installation of blocks (= extracting to the working directory of the web
   application) is NOT the responsibility of the Spring configurator.

* The installation of blocks shouldn't be done by using Spring so that the list
   of all installed blocks is generally available.


So what do we propose?
----------------------

* Get rid of the SourceResolver usage in the SSF implementation code.

* Do the installation of blocks in a ServletContextListener. The map of all
   installed blocks can be stored as a servlet context attribute then and
   being looked up from there easily.

* Provide a Spring aspect that intercepts all service() method calls using
   an around advice and installs a URLStreamHandlerFactory (-> that's the piece
   of code responsible for returning the correct StreamHandler for a particular
   protocol). The list of available StreamHanlders can be gathered by using
   a BeanMap that collects all beans of a particular type.

   Doing it this way ensures that the installation and uninstallation of
   URLStreamHandlerFactories is done per thread and we are on the safe side
   when there is more than one web application running the same JVM.

As a first step we want to make these changes happen without creating any
additional modules. But when things become more stable (implementation-wise) we
will propose to create a separate module for the "BlockInstaller" and find the 
final home for "JNet".

-- 
Reinhard P�tz                            Managing Director, {Indoqa} GmbH
                           http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair        reinhard@apache.org
_________________________________________________________________________