You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2008/04/08 13:54:47 UTC
JNet integration
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
_________________________________________________________________________
Re: JNet integration
Posted by Vadim Gritsenko <va...@reverycodes.com>.
On Apr 8, 2008, at 7:54 AM, Reinhard Poetz wrote:
>
> 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".
Sounds good to me.
Vadim
Re: JNet integration
Posted by Reinhard Poetz <re...@apache.org>.
Reinhard Poetz wrote:
>
> 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.
It's done so far and working AFAICT.
> 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".
As a next step I will create separate modules for them. Then we can discuss the
scope of each in more detail and find the final home of 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
_________________________________________________________________________