You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/10/18 17:41:10 UTC
[RT] Environment Revamping
Currently, the Environment system has grown to provide an abstraction
layer so that Cocoon logic can function equally well depending on whatever
the environment is. This is a good thing, and in my opinion very necessary.
However, what we have in our API can get confusing both for Cocoon app
developers, and for environment adaptor providers.
Because Cocoon began life as a Servlet, the environment is heavily slanted
in that direction. While I do not want to reinvent the wheel that the
servlet vendors have created, we can simplify our API so that app developers
have an easier time. Currently, the Environment consists of the following
interfaces:
* Environment
* Context
* Cookie
* Redirector
* Request
* Response
* Session
* Source
* SourceResolver
In addition to this we have the Avalon Context that we are using within
the rest of the API for Cocoon system properties. Some of this is a bit
much, and can be merged, and we can have a simpler API because of it.
Granted that this would require deprecating some pieces in the HEAD
branch of CVS, but I think we would be better for it in the long run.
First, we have to consider what each piece is used for.
INSTALLATION SPECIFIC API
org.apache.avalon.framework.context.Context
org.apache.cocoon.environment.Context
SourceResolver
Source
SESSION SPECIFIC API
Session
REQUEST SPECIFIC API
Redirector
Request
Response
Map (ObjectModel)
PERSISTENT CLIENT STORAGE
Cookie
In addition to all this, the ObjectModel is simply a Map that allows access
to all of the APIs as we need them. It is clear that too many indirections
(i.e. Maps) create a more cluttered API. What should we do then? Clearly
there are two major categories of Context. There is the system context which
provides meta information about the installation. Then there is the request
specific context which allows us to pass information between stages, and
access the session and client storage mechanisms.
In order to simplify, I believe that there should be 2 Context objects to
worry about: SystemContext and RequestContext. The SystemContext object
would extend the AvalonContext--and be passed to any Contextualizable
Component. So what would this look like:
public interface SystemContext extends org.apache.avalon.framework.context.Context {
Source resolve(String uri);
org.apache.cocoon.environment.Context getEnvironmentContext();
Object get(Object key); // from Avalon context
}
This removes the need for the SourceResolver interface to be exposed or passed
as an argument to Components. Components that do not need it or use it will
have access to a simpler API.
The other Context woudl be the RequestContext. That API would be like this:
public interface RequestContext extends Map {
Request getRequest();
Session getSession();
Session getSession(boolean forceNew);
Response getResponse();
void redirect(String uri); // throws IllegalStateException if called after generator setup.
Object get(Object key); // from Map
void put(Object key, Object value); // from Map
}
This makes the RequestContext compatible with ObjectModel as it stands now--
not forcing any MAJOR changes to the API. It also removes the need of exposing
the Redirector interface to the clients as a passed argument. While it may
seem tempting to do so, most developers will get the clue very quickly that
it can only be done from the SetUp method. This will expose it to be used to
generators and transformers alike, but the distinct difference is that the
setup and generate commands are separate.
This also simplifies client code--and the get/put methods in the RequestContext,
but it also minimizes the overhead involved in looking up the specific environment
interfaces from a generic Map.
You'll notice that the Environment interface is missing. That is because the
Environment interface has been identified as the contract between the sitemap
and the environment that Cocoon is living in.
Lastly, this will also open up API optimizations in that we can simplify the
signatures to setUp(RequestContext context, String source, Parameters params);
If there is some new interface that needs to be supplied to the sitemap
components, it will be done through the RequestContext or SystemContext objects
as is appropriate.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Environment Revamping
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
>
> Currently, the Environment system has grown to provide an abstraction
> layer so that Cocoon logic can function equally well depending on whatever
> the environment is. This is a good thing, and in my opinion very necessary.
> However, what we have in our API can get confusing both for Cocoon app
> developers, and for environment adaptor providers.
>
> Because Cocoon began life as a Servlet, the environment is heavily slanted
> in that direction. While I do not want to reinvent the wheel that the
> servlet vendors have created, we can simplify our API so that app developers
> have an easier time. Currently, the Environment consists of the following
> interfaces:
>
> * Environment
> * Context
> * Cookie
> * Redirector
> * Request
> * Response
> * Session
> * Source
> * SourceResolver
>
> In addition to this we have the Avalon Context that we are using within
> the rest of the API for Cocoon system properties. Some of this is a bit
> much, and can be merged, and we can have a simpler API because of it.
> Granted that this would require deprecating some pieces in the HEAD
> branch of CVS, but I think we would be better for it in the long run.
> First, we have to consider what each piece is used for.
>
> INSTALLATION SPECIFIC API
> org.apache.avalon.framework.context.Context
> org.apache.cocoon.environment.Context
> SourceResolver
> Source
>
> SESSION SPECIFIC API
> Session
>
> REQUEST SPECIFIC API
> Redirector
> Request
> Response
> Map (ObjectModel)
>
> PERSISTENT CLIENT STORAGE
> Cookie
>
> In addition to all this, the ObjectModel is simply a Map that allows access
> to all of the APIs as we need them. It is clear that too many indirections
> (i.e. Maps) create a more cluttered API. What should we do then? Clearly
> there are two major categories of Context. There is the system context which
> provides meta information about the installation. Then there is the request
> specific context which allows us to pass information between stages, and
> access the session and client storage mechanisms.
>
> In order to simplify, I believe that there should be 2 Context objects to
> worry about: SystemContext and RequestContext. The SystemContext object
> would extend the AvalonContext--and be passed to any Contextualizable
> Component. So what would this look like:
>
> public interface SystemContext extends org.apache.avalon.framework.context.Context {
> Source resolve(String uri);
> org.apache.cocoon.environment.Context getEnvironmentContext();
> Object get(Object key); // from Avalon context
> }
>
> This removes the need for the SourceResolver interface to be exposed or passed
> as an argument to Components. Components that do not need it or use it will
> have access to a simpler API.
>
> The other Context woudl be the RequestContext. That API would be like this:
>
> public interface RequestContext extends Map {
> Request getRequest();
> Session getSession();
> Session getSession(boolean forceNew);
> Response getResponse();
> void redirect(String uri); // throws IllegalStateException if called after generator setup.
> Object get(Object key); // from Map
> void put(Object key, Object value); // from Map
> }
>
> This makes the RequestContext compatible with ObjectModel as it stands now--
> not forcing any MAJOR changes to the API. It also removes the need of exposing
> the Redirector interface to the clients as a passed argument. While it may
> seem tempting to do so, most developers will get the clue very quickly that
> it can only be done from the SetUp method. This will expose it to be used to
> generators and transformers alike, but the distinct difference is that the
> setup and generate commands are separate.
>
> This also simplifies client code--and the get/put methods in the RequestContext,
> but it also minimizes the overhead involved in looking up the specific environment
> interfaces from a generic Map.
>
> You'll notice that the Environment interface is missing. That is because the
> Environment interface has been identified as the contract between the sitemap
> and the environment that Cocoon is living in.
>
> Lastly, this will also open up API optimizations in that we can simplify the
> signatures to setUp(RequestContext context, String source, Parameters params);
> If there is some new interface that needs to be supplied to the sitemap
> components, it will be done through the RequestContext or SystemContext objects
> as is appropriate.
Everything sounds very reasonable.
I'm all in favor of doing something like this. +1.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Environment Revamping
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
>
> +1. If we can solve the problem outlined by Carsten
> (SitemapSystemContext that wraps the SystemContext and overrides
> resove() ?), this will allow uniform access to input sources from
> everywhere, instead of using URLFactories when a SourceResolver isn't
> available.
See my response to Carsten. I would prefer moving it to the
RequestContext.
> A question about get() : is it a shortcut for
> getEnvironmentContext().get(), or does the SystemContext hold additional
> values, and if so, which ones ?
No, it is not a shortcut. The SystemContext extends the Avalon Context
object. The get() here is the one from the Context interface. It is used
for the values you get through the Contextualizable.contextualize() method.
Note that it is read only for a reason....
> > The other Context woudl be the RequestContext. That API would be like this:
> >
> > public interface RequestContext extends Map {
> > Request getRequest();
> > Session getSession();
> > Session getSession(boolean forceNew);
> > Response getResponse();
> > void redirect(String uri); // throws IllegalStateException if called after generator setup.
> > Object get(Object key); // from Map
> > void put(Object key, Object value); // from Map
> > }
> >
> > This makes the RequestContext compatible with ObjectModel as it stands now--
> > not forcing any MAJOR changes to the API. It also removes the need of exposing
> > the Redirector interface to the clients as a passed argument. While it may
> > seem tempting to do so, most developers will get the clue very quickly that
> > it can only be done from the SetUp method. This will expose it to be used to
> > generators and transformers alike, but the distinct difference is that the
> > setup and generate commands are separate.
>
> Extending Map is a good idea : only the parameter type will change, so
> this will require only a recompilation without code change (provided
> that we route get(RESPONSE_OBJECT) to getResponse(), etc). But this also
> clearly states that data can be added to the object model using put().
> There has been several posts in the past giving me the impression this
> was possible, but not encouraged. Was this impression wrong ?
We have multiple issues here. The RequestContext needs to be the same (or equivalent)
object for the life of the request. This allows property passing between stages
during setup phases. Currently you have to do that through the Request interface.
If we do not want to simplify and allow the RequestContext the same object for the
life of the request, then we should extend Avalon Context which is read only.
In any regards, the RequestContext MUST protect the values in RESPONSE_OBJECT, et al.
Because we have an object that we control the code, we can safely do that now. And for
back compatibility, I would require that the RESPONSE_OBJECT and similar entries be
kept for as long as the deprecation period.
> > This also simplifies client code--and the get/put methods in the RequestContext,
> > but it also minimizes the overhead involved in looking up the specific environment
> > interfaces from a generic Map.
> >
> > You'll notice that the Environment interface is missing. That is because the
> > Environment interface has been identified as the contract between the sitemap
> > and the environment that Cocoon is living in.
> >
> > Lastly, this will also open up API optimizations in that we can simplify the
> > signatures to setUp(RequestContext context, String source, Parameters params);
> > If there is some new interface that needs to be supplied to the sitemap
> > components, it will be done through the RequestContext or SystemContext objects
> > as is appropriate.
>
> +1. This will also easy extension in the future if need : just add
> method on RequestContext, without changing the interfaces.
That was my whole idea.
> And also quoting Carsten, which version will have all this ? There are a
> number of interesting changes proposed these days, but we're also
> discussing about the 2.0 final release date.
I don't want to hold up the 2.0 release date. This should be aimed at 2.1.
> Should we release a 2.0 quickly and include these changes in 2.1 at the
> price of incompatibility, or should we put them in 2.0, even if this
> delays it a little bit ? I don't have a definite opinion about that
> since I don't have the same urge for a final version as some of you (our
> customers accept a Release Canditate if we support it).
Use deprecation. It is a tool to allow backwards compatibility, but steer
new and revamped development to the correct methods. If the deprecation lives
for at least a year, it allows a nice migration period.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Environment Revamping
Posted by Carsten Ziegeler <cz...@sundn.de>.
Berin Loritsch wrote:
> Martin Man wrote:
> >
> > On Fri, Oct 19, 2001 at 12:08:15PM +0200, Sylvain Wallez wrote:
> > >
> > > Extending Map is a good idea : only the parameter type will change, so
> > > this will require only a recompilation without code change (provided
> > > that we route get(RESPONSE_OBJECT) to getResponse(), etc).
> But this also
> > > clearly states that data can be added to the object model using put().
> > > There has been several posts in the past giving me the impression this
> > > was possible, but not encouraged. Was this impression wrong ?
> >
> > no you're sure the discussion was about using the objectModel
> as a generic
> > communication space for component exchange between different pipeline
> > components, eg. generator (or action) placing something to the
> objectModel and
> > transformer taking it out, ....
> >
> > but if I recall correctly giacomo (and I agree) stated that
> this should not be
> > used at all and proposed to meke the objectModel readOnly to
> avoid confusion,
> > becuase there are already objects like session and request that
> are suited for
> > this type of communication
> >
> > so my 0.2 cents are to make new RequestContext readOnly for
> adding new objects
> > to it and provide some set/getAttribute methods which will wrap
> the existing
> > set/getAttribute methods for different underlying contexts...
>
> In that case, RequestContext should extend Avalon Context, which
> only exposes
> the get() method. Any well behaved component will survive with
> only a recompile
> necessary.
>
The main reason why we decided that the objectModel is still a map,
is that some servlet engines have problems storing not Serializable
objects into the request attributes, e.g. BEA WLS 6.x.
So there are situations where you can't use the Request Object
to hold something. But you can use the objectModel.
So I am still +1 to have a set() method as well otherwise life
with WLS will be very hard.
Carsten
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Environment Revamping
Posted by Berin Loritsch <bl...@apache.org>.
Martin Man wrote:
>
> On Fri, Oct 19, 2001 at 12:08:15PM +0200, Sylvain Wallez wrote:
> >
> > Extending Map is a good idea : only the parameter type will change, so
> > this will require only a recompilation without code change (provided
> > that we route get(RESPONSE_OBJECT) to getResponse(), etc). But this also
> > clearly states that data can be added to the object model using put().
> > There has been several posts in the past giving me the impression this
> > was possible, but not encouraged. Was this impression wrong ?
>
> no you're sure the discussion was about using the objectModel as a generic
> communication space for component exchange between different pipeline
> components, eg. generator (or action) placing something to the objectModel and
> transformer taking it out, ....
>
> but if I recall correctly giacomo (and I agree) stated that this should not be
> used at all and proposed to meke the objectModel readOnly to avoid confusion,
> becuase there are already objects like session and request that are suited for
> this type of communication
>
> so my 0.2 cents are to make new RequestContext readOnly for adding new objects
> to it and provide some set/getAttribute methods which will wrap the existing
> set/getAttribute methods for different underlying contexts...
In that case, RequestContext should extend Avalon Context, which only exposes
the get() method. Any well behaved component will survive with only a recompile
necessary.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Environment Revamping
Posted by Martin Man <Ma...@seznam.cz>.
On Fri, Oct 19, 2001 at 12:08:15PM +0200, Sylvain Wallez wrote:
>
> Extending Map is a good idea : only the parameter type will change, so
> this will require only a recompilation without code change (provided
> that we route get(RESPONSE_OBJECT) to getResponse(), etc). But this also
> clearly states that data can be added to the object model using put().
> There has been several posts in the past giving me the impression this
> was possible, but not encouraged. Was this impression wrong ?
no you're sure the discussion was about using the objectModel as a generic
communication space for component exchange between different pipeline
components, eg. generator (or action) placing something to the objectModel and
transformer taking it out, ....
but if I recall correctly giacomo (and I agree) stated that this should not be
used at all and proposed to meke the objectModel readOnly to avoid confusion,
becuase there are already objects like session and request that are suited for
this type of communication
so my 0.2 cents are to make new RequestContext readOnly for adding new objects
to it and provide some set/getAttribute methods which will wrap the existing
set/getAttribute methods for different underlying contexts...
>
> Sylvain.
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
martin
--
2CC0 4AF6 92DA 5CBF 5F09 7BCB 6202 7024 6E06 0223
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Environment Revamping
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch a écrit :
>
> Currently, the Environment system has grown to provide an abstraction
> layer so that Cocoon logic can function equally well depending on whatever
> the environment is. This is a good thing, and in my opinion very necessary.
> However, what we have in our API can get confusing both for Cocoon app
> developers, and for environment adaptor providers.
>
> Because Cocoon began life as a Servlet, the environment is heavily slanted
> in that direction. While I do not want to reinvent the wheel that the
> servlet vendors have created, we can simplify our API so that app developers
> have an easier time. Currently, the Environment consists of the following
> interfaces:
>
> * Environment
> * Context
> * Cookie
> * Redirector
> * Request
> * Response
> * Session
> * Source
> * SourceResolver
>
> In addition to this we have the Avalon Context that we are using within
> the rest of the API for Cocoon system properties. Some of this is a bit
> much, and can be merged, and we can have a simpler API because of it.
> Granted that this would require deprecating some pieces in the HEAD
> branch of CVS, but I think we would be better for it in the long run.
> First, we have to consider what each piece is used for.
>
> INSTALLATION SPECIFIC API
> org.apache.avalon.framework.context.Context
> org.apache.cocoon.environment.Context
> SourceResolver
> Source
>
> SESSION SPECIFIC API
> Session
>
> REQUEST SPECIFIC API
> Redirector
> Request
> Response
> Map (ObjectModel)
>
> PERSISTENT CLIENT STORAGE
> Cookie
>
> In addition to all this, the ObjectModel is simply a Map that allows access
> to all of the APIs as we need them. It is clear that too many indirections
> (i.e. Maps) create a more cluttered API. What should we do then? Clearly
> there are two major categories of Context. There is the system context which
> provides meta information about the installation. Then there is the request
> specific context which allows us to pass information between stages, and
> access the session and client storage mechanisms.
>
> In order to simplify, I believe that there should be 2 Context objects to
> worry about: SystemContext and RequestContext. The SystemContext object
> would extend the AvalonContext--and be passed to any Contextualizable
> Component. So what would this look like:
>
> public interface SystemContext extends org.apache.avalon.framework.context.Context {
> Source resolve(String uri);
> org.apache.cocoon.environment.Context getEnvironmentContext();
> Object get(Object key); // from Avalon context
> }
>
> This removes the need for the SourceResolver interface to be exposed or passed
> as an argument to Components. Components that do not need it or use it will
> have access to a simpler API.
+1. If we can solve the problem outlined by Carsten
(SitemapSystemContext that wraps the SystemContext and overrides
resove() ?), this will allow uniform access to input sources from
everywhere, instead of using URLFactories when a SourceResolver isn't
available.
A question about get() : is it a shortcut for
getEnvironmentContext().get(), or does the SystemContext hold additional
values, and if so, which ones ?
> The other Context woudl be the RequestContext. That API would be like this:
>
> public interface RequestContext extends Map {
> Request getRequest();
> Session getSession();
> Session getSession(boolean forceNew);
> Response getResponse();
> void redirect(String uri); // throws IllegalStateException if called after generator setup.
> Object get(Object key); // from Map
> void put(Object key, Object value); // from Map
> }
>
> This makes the RequestContext compatible with ObjectModel as it stands now--
> not forcing any MAJOR changes to the API. It also removes the need of exposing
> the Redirector interface to the clients as a passed argument. While it may
> seem tempting to do so, most developers will get the clue very quickly that
> it can only be done from the SetUp method. This will expose it to be used to
> generators and transformers alike, but the distinct difference is that the
> setup and generate commands are separate.
Extending Map is a good idea : only the parameter type will change, so
this will require only a recompilation without code change (provided
that we route get(RESPONSE_OBJECT) to getResponse(), etc). But this also
clearly states that data can be added to the object model using put().
There has been several posts in the past giving me the impression this
was possible, but not encouraged. Was this impression wrong ?
> This also simplifies client code--and the get/put methods in the RequestContext,
> but it also minimizes the overhead involved in looking up the specific environment
> interfaces from a generic Map.
>
> You'll notice that the Environment interface is missing. That is because the
> Environment interface has been identified as the contract between the sitemap
> and the environment that Cocoon is living in.
>
> Lastly, this will also open up API optimizations in that we can simplify the
> signatures to setUp(RequestContext context, String source, Parameters params);
> If there is some new interface that needs to be supplied to the sitemap
> components, it will be done through the RequestContext or SystemContext objects
> as is appropriate.
+1. This will also easy extension in the future if need : just add
method on RequestContext, without changing the interfaces.
And also quoting Carsten, which version will have all this ? There are a
number of interesting changes proposed these days, but we're also
discussing about the 2.0 final release date.
Should we release a 2.0 quickly and include these changes in 2.1 at the
price of incompatibility, or should we put them in 2.0, even if this
delays it a little bit ? I don't have a definite opinion about that
since I don't have the same urge for a final version as some of you (our
customers accept a Release Canditate if we support it).
Sylvain.
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Environment Revamping
Posted by Martin Man <Ma...@seznam.cz>.
hi all,
as I was already +1 on sylvian's objectModelHelper and this is logical
cleanup and improvement, am of course even +2 for this...
On Thu, Oct 18, 2001 at 11:41:10AM -0400, Berin Loritsch wrote:
> Currently, the Environment system has grown to provide an abstraction
> layer so that Cocoon logic can function equally well depending on whatever
> the environment is. This is a good thing, and in my opinion very necessary.
> However, what we have in our API can get confusing both for Cocoon app
> developers, and for environment adaptor providers.
>
> Because Cocoon began life as a Servlet, the environment is heavily slanted
> in that direction. While I do not want to reinvent the wheel that the
> servlet vendors have created, we can simplify our API so that app developers
> have an easier time. Currently, the Environment consists of the following
> interfaces:
>
> * Environment
> * Context
> * Cookie
> * Redirector
> * Request
> * Response
> * Session
> * Source
> * SourceResolver
>
> In addition to this we have the Avalon Context that we are using within
> the rest of the API for Cocoon system properties. Some of this is a bit
> much, and can be merged, and we can have a simpler API because of it.
> Granted that this would require deprecating some pieces in the HEAD
> branch of CVS, but I think we would be better for it in the long run.
> First, we have to consider what each piece is used for.
>
> INSTALLATION SPECIFIC API
> org.apache.avalon.framework.context.Context
> org.apache.cocoon.environment.Context
> SourceResolver
> Source
>
> SESSION SPECIFIC API
> Session
>
> REQUEST SPECIFIC API
> Redirector
> Request
> Response
> Map (ObjectModel)
>
> PERSISTENT CLIENT STORAGE
> Cookie
>
>
> In addition to all this, the ObjectModel is simply a Map that allows access
> to all of the APIs as we need them. It is clear that too many indirections
> (i.e. Maps) create a more cluttered API. What should we do then? Clearly
> there are two major categories of Context. There is the system context which
> provides meta information about the installation. Then there is the request
> specific context which allows us to pass information between stages, and
> access the session and client storage mechanisms.
>
> In order to simplify, I believe that there should be 2 Context objects to
> worry about: SystemContext and RequestContext. The SystemContext object
> would extend the AvalonContext--and be passed to any Contextualizable
> Component. So what would this look like:
>
> public interface SystemContext extends org.apache.avalon.framework.context.Context {
> Source resolve(String uri);
> org.apache.cocoon.environment.Context getEnvironmentContext();
> Object get(Object key); // from Avalon context
> }
>
> This removes the need for the SourceResolver interface to be exposed or passed
> as an argument to Components. Components that do not need it or use it will
> have access to a simpler API.
>
> The other Context woudl be the RequestContext. That API would be like this:
>
> public interface RequestContext extends Map {
> Request getRequest();
> Session getSession();
> Session getSession(boolean forceNew);
> Response getResponse();
> void redirect(String uri); // throws IllegalStateException if called after generator setup.
> Object get(Object key); // from Map
> void put(Object key, Object value); // from Map
> }
>
> This makes the RequestContext compatible with ObjectModel as it stands now--
> not forcing any MAJOR changes to the API. It also removes the need of exposing
> the Redirector interface to the clients as a passed argument. While it may
> seem tempting to do so, most developers will get the clue very quickly that
> it can only be done from the SetUp method. This will expose it to be used to
> generators and transformers alike, but the distinct difference is that the
> setup and generate commands are separate.
>
> This also simplifies client code--and the get/put methods in the RequestContext,
> but it also minimizes the overhead involved in looking up the specific environment
> interfaces from a generic Map.
>
> You'll notice that the Environment interface is missing. That is because the
> Environment interface has been identified as the contract between the sitemap
> and the environment that Cocoon is living in.
>
> Lastly, this will also open up API optimizations in that we can simplify the
> signatures to setUp(RequestContext context, String source, Parameters params);
> If there is some new interface that needs to be supplied to the sitemap
> components, it will be done through the RequestContext or SystemContext objects
> as is appropriate.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
--
2CC0 4AF6 92DA 5CBF 5F09 7BCB 6202 7024 6E06 0223
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Environment Revamping
Posted by Berin Loritsch <bl...@apache.org>.
giacomo wrote:
>
> On Thu, 18 Oct 2001, Berin Loritsch wrote:
>
> Cool analysis and explanation of the moves to take.
>
> Do you have an idea of how much time it needs to do the move?
> Did you indent it to go into 2.0 or 2.1?
>
> Anyway you have my +1 for it.
I intend it for 2.1, and it will take a few hours to accomplish.
>
> Giacomo
>
> > Currently, the Environment system has grown to provide an abstraction
> > layer so that Cocoon logic can function equally well depending on whatever
> > the environment is. This is a good thing, and in my opinion very necessary.
> > However, what we have in our API can get confusing both for Cocoon app
> > developers, and for environment adaptor providers.
> >
> > Because Cocoon began life as a Servlet, the environment is heavily slanted
> > in that direction. While I do not want to reinvent the wheel that the
> > servlet vendors have created, we can simplify our API so that app developers
> > have an easier time. Currently, the Environment consists of the following
> > interfaces:
> >
> > * Environment
> > * Context
> > * Cookie
> > * Redirector
> > * Request
> > * Response
> > * Session
> > * Source
> > * SourceResolver
> >
> > In addition to this we have the Avalon Context that we are using within
> > the rest of the API for Cocoon system properties. Some of this is a bit
> > much, and can be merged, and we can have a simpler API because of it.
> > Granted that this would require deprecating some pieces in the HEAD
> > branch of CVS, but I think we would be better for it in the long run.
> > First, we have to consider what each piece is used for.
> >
> > INSTALLATION SPECIFIC API
> > org.apache.avalon.framework.context.Context
> > org.apache.cocoon.environment.Context
> > SourceResolver
> > Source
> >
> > SESSION SPECIFIC API
> > Session
> >
> > REQUEST SPECIFIC API
> > Redirector
> > Request
> > Response
> > Map (ObjectModel)
> >
> > PERSISTENT CLIENT STORAGE
> > Cookie
> >
> >
> > In addition to all this, the ObjectModel is simply a Map that allows access
> > to all of the APIs as we need them. It is clear that too many indirections
> > (i.e. Maps) create a more cluttered API. What should we do then? Clearly
> > there are two major categories of Context. There is the system context which
> > provides meta information about the installation. Then there is the request
> > specific context which allows us to pass information between stages, and
> > access the session and client storage mechanisms.
> >
> > In order to simplify, I believe that there should be 2 Context objects to
> > worry about: SystemContext and RequestContext. The SystemContext object
> > would extend the AvalonContext--and be passed to any Contextualizable
> > Component. So what would this look like:
> >
> > public interface SystemContext extends org.apache.avalon.framework.context.Context {
> > Source resolve(String uri);
> > org.apache.cocoon.environment.Context getEnvironmentContext();
> > Object get(Object key); // from Avalon context
> > }
> >
> > This removes the need for the SourceResolver interface to be exposed or passed
> > as an argument to Components. Components that do not need it or use it will
> > have access to a simpler API.
> >
> > The other Context woudl be the RequestContext. That API would be like this:
> >
> > public interface RequestContext extends Map {
> > Request getRequest();
> > Session getSession();
> > Session getSession(boolean forceNew);
> > Response getResponse();
> > void redirect(String uri); // throws IllegalStateException if called after generator setup.
> > Object get(Object key); // from Map
> > void put(Object key, Object value); // from Map
> > }
> >
> > This makes the RequestContext compatible with ObjectModel as it stands now--
> > not forcing any MAJOR changes to the API. It also removes the need of exposing
> > the Redirector interface to the clients as a passed argument. While it may
> > seem tempting to do so, most developers will get the clue very quickly that
> > it can only be done from the SetUp method. This will expose it to be used to
> > generators and transformers alike, but the distinct difference is that the
> > setup and generate commands are separate.
> >
> > This also simplifies client code--and the get/put methods in the RequestContext,
> > but it also minimizes the overhead involved in looking up the specific environment
> > interfaces from a generic Map.
> >
> > You'll notice that the Environment interface is missing. That is because the
> > Environment interface has been identified as the contract between the sitemap
> > and the environment that Cocoon is living in.
> >
> > Lastly, this will also open up API optimizations in that we can simplify the
> > signatures to setUp(RequestContext context, String source, Parameters params);
> > If there is some new interface that needs to be supplied to the sitemap
> > components, it will be done through the RequestContext or SystemContext objects
> > as is appropriate.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Environment Revamping
Posted by giacomo <gi...@apache.org>.
On Thu, 18 Oct 2001, Berin Loritsch wrote:
Cool analysis and explanation of the moves to take.
Do you have an idea of how much time it needs to do the move?
Did you indent it to go into 2.0 or 2.1?
Anyway you have my +1 for it.
Giacomo
> Currently, the Environment system has grown to provide an abstraction
> layer so that Cocoon logic can function equally well depending on whatever
> the environment is. This is a good thing, and in my opinion very necessary.
> However, what we have in our API can get confusing both for Cocoon app
> developers, and for environment adaptor providers.
>
> Because Cocoon began life as a Servlet, the environment is heavily slanted
> in that direction. While I do not want to reinvent the wheel that the
> servlet vendors have created, we can simplify our API so that app developers
> have an easier time. Currently, the Environment consists of the following
> interfaces:
>
> * Environment
> * Context
> * Cookie
> * Redirector
> * Request
> * Response
> * Session
> * Source
> * SourceResolver
>
> In addition to this we have the Avalon Context that we are using within
> the rest of the API for Cocoon system properties. Some of this is a bit
> much, and can be merged, and we can have a simpler API because of it.
> Granted that this would require deprecating some pieces in the HEAD
> branch of CVS, but I think we would be better for it in the long run.
> First, we have to consider what each piece is used for.
>
> INSTALLATION SPECIFIC API
> org.apache.avalon.framework.context.Context
> org.apache.cocoon.environment.Context
> SourceResolver
> Source
>
> SESSION SPECIFIC API
> Session
>
> REQUEST SPECIFIC API
> Redirector
> Request
> Response
> Map (ObjectModel)
>
> PERSISTENT CLIENT STORAGE
> Cookie
>
>
> In addition to all this, the ObjectModel is simply a Map that allows access
> to all of the APIs as we need them. It is clear that too many indirections
> (i.e. Maps) create a more cluttered API. What should we do then? Clearly
> there are two major categories of Context. There is the system context which
> provides meta information about the installation. Then there is the request
> specific context which allows us to pass information between stages, and
> access the session and client storage mechanisms.
>
> In order to simplify, I believe that there should be 2 Context objects to
> worry about: SystemContext and RequestContext. The SystemContext object
> would extend the AvalonContext--and be passed to any Contextualizable
> Component. So what would this look like:
>
> public interface SystemContext extends org.apache.avalon.framework.context.Context {
> Source resolve(String uri);
> org.apache.cocoon.environment.Context getEnvironmentContext();
> Object get(Object key); // from Avalon context
> }
>
> This removes the need for the SourceResolver interface to be exposed or passed
> as an argument to Components. Components that do not need it or use it will
> have access to a simpler API.
>
> The other Context woudl be the RequestContext. That API would be like this:
>
> public interface RequestContext extends Map {
> Request getRequest();
> Session getSession();
> Session getSession(boolean forceNew);
> Response getResponse();
> void redirect(String uri); // throws IllegalStateException if called after generator setup.
> Object get(Object key); // from Map
> void put(Object key, Object value); // from Map
> }
>
> This makes the RequestContext compatible with ObjectModel as it stands now--
> not forcing any MAJOR changes to the API. It also removes the need of exposing
> the Redirector interface to the clients as a passed argument. While it may
> seem tempting to do so, most developers will get the clue very quickly that
> it can only be done from the SetUp method. This will expose it to be used to
> generators and transformers alike, but the distinct difference is that the
> setup and generate commands are separate.
>
> This also simplifies client code--and the get/put methods in the RequestContext,
> but it also minimizes the overhead involved in looking up the specific environment
> interfaces from a generic Map.
>
> You'll notice that the Environment interface is missing. That is because the
> Environment interface has been identified as the contract between the sitemap
> and the environment that Cocoon is living in.
>
> Lastly, this will also open up API optimizations in that we can simplify the
> signatures to setUp(RequestContext context, String source, Parameters params);
> If there is some new interface that needs to be supplied to the sitemap
> components, it will be done through the RequestContext or SystemContext objects
> as is appropriate.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Environment Revamping
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> > Berin Loritsch wrote:
> >
> > Carsten Ziegeler wrote:
> > >
> >
> > > > public interface SystemContext extends
> > > > org.apache.avalon.framework.context.Context {
> > > > Source resolve(String uri);
> > > > org.apache.cocoon.environment.Context getEnvironmentContext();
> > > > Object get(Object key); // from Avalon context
> > > > }
> > > >
> > > > This removes the need for the SourceResolver interface to be
> > > > exposed or passed
> > > > as an argument to Components. Components that do not need it or
> > > > use it will
> > > > have access to a simpler API.
> > > >
> > > The intention of this interface is very good, I like it, but
> > > I see one (more technical) problem here: the resolve() method
> > > is Environment or Request dependant. This means, if a component
> > > (e.g. the store) is contextualized at startup and gets the
> > > SystemContext, the resolving of resources must be done
> > > with the current environment in mind which might result in
> > > different resources.
> > > This resolving with respect to the current environment is
> > > of course necessary for all sitemap components (generators
> > > etc).
> > > If we get this working: +1
> >
> >
> > Ok, with that clarification, the resolve method would move to
> > RequestContext.
> >
> > > What do you mean with the org.apache.cocoon.environment.Context
> > > object? Is this the RequestContext mentioned below?
> >
> > No, that is the equivalent of the ServletContext. It is global in scope,
> > and only a few components _really_ need it. If you need it, extend
> > Contextualizable, and cast the Context to SystemContext.
> >
> Sorry, I was not very clear here:
> I meant the object returned getEnvironmentContext().
That's what I thought you meant. getEnvironmentContext() returns the
same object as get(CONTEXT_OBJECT); on objectModel now. It is a global
concern, not a request specific concern.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Environment Revamping
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Berin Loritsch wrote:
>
> Carsten Ziegeler wrote:
> >
>
> > > public interface SystemContext extends
> > > org.apache.avalon.framework.context.Context {
> > > Source resolve(String uri);
> > > org.apache.cocoon.environment.Context getEnvironmentContext();
> > > Object get(Object key); // from Avalon context
> > > }
> > >
> > > This removes the need for the SourceResolver interface to be
> > > exposed or passed
> > > as an argument to Components. Components that do not need it or
> > > use it will
> > > have access to a simpler API.
> > >
> > The intention of this interface is very good, I like it, but
> > I see one (more technical) problem here: the resolve() method
> > is Environment or Request dependant. This means, if a component
> > (e.g. the store) is contextualized at startup and gets the
> > SystemContext, the resolving of resources must be done
> > with the current environment in mind which might result in
> > different resources.
> > This resolving with respect to the current environment is
> > of course necessary for all sitemap components (generators
> > etc).
> > If we get this working: +1
>
>
> Ok, with that clarification, the resolve method would move to
> RequestContext.
>
> > What do you mean with the org.apache.cocoon.environment.Context
> > object? Is this the RequestContext mentioned below?
>
> No, that is the equivalent of the ServletContext. It is global in scope,
> and only a few components _really_ need it. If you need it, extend
> Contextualizable, and cast the Context to SystemContext.
>
Sorry, I was not very clear here:
I meant the object returned getEnvironmentContext().
> > > Lastly, this will also open up API optimizations in that we can
> > > simplify the
> > > signatures to setUp(RequestContext context, String source,
> > > Parameters params);
> > > If there is some new interface that needs to be supplied to
> the sitemap
> > > components, it will be done through the RequestContext or
> > > SystemContext objects
> > > as is appropriate.
> > >
> > +1
> >
> > What about the Interface Cookie you mentioned above? I personally would
> > like to clean up Request/Response interfaces.
> > There are certainly Environments which do not use Cookies and for
> > example don't know anything about headers. So I would like to separate
> > them from the Request/Response so that one could test if the
> > current environment supports this feature or not.
>
> Hmm. If an environment doesn't support a feature, then it should
> ignore it--in the case of headers. As to the Cookies--Cookies are
> persistent client storage. Persistent in the fact that they can last
> between sessions--not that they live forever (although sometimes it
> seems like it).
>
> In the cases where Cookies are not supported, we should follow the
> standards of how Servlets handle the case when Cookies are turned
> off. If there is no standard, we can throw a
> UnsupportedOperationException
> or something similar. It would have to extend Runtime exception
> though.
>
> If you have specific API cleanups for Request/Response, we can go through
> them as well. I was wanting to simplify the UI as much as possible
> for the HEAD branch.
>
Yes, that's great: I would like to have the minimum methods on those
interfaces as possible. That's why I thought about "outsourcing"
for example the Header stuff.
Headers are optional. An environment can of course ignore them, but
if a user of a request object calls setHeader() etc. it expects
that the header is really set.
If it can beforehand test, if headers are supported, that's for
me a cleaner solution. This test could either be done by separate
marker-like interfaces or by "supportsHeaders()" methods.
But - as Ovidiu stated recently - we should keep in mind to support
in any way most methods/features the servlet environment offers.
I will try to come up next week with a proposal for Request
and Response objects.
Carsten
>
> > By the way: About what timeframe and version are we talking here?
>
>
> These are changes to HEAD. It should be done sooner than later so we
> don't forget about them. But it is good for Cocoon 2.1. The arrangement
> allows use to simply deprecate the unused methods and point users to
> the real implementation. The deprecated methods should live for at least
> a year--that way as projects naturally upgrade, they can move to the
> new API. With the LogKit, we found that 5.5 months was not long enough
> for projects to migrate.
>
> P.S. This should not delay Cocoon 2.0 final.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Environment Revamping
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> > public interface SystemContext extends
> > org.apache.avalon.framework.context.Context {
> > Source resolve(String uri);
> > org.apache.cocoon.environment.Context getEnvironmentContext();
> > Object get(Object key); // from Avalon context
> > }
> >
> > This removes the need for the SourceResolver interface to be
> > exposed or passed
> > as an argument to Components. Components that do not need it or
> > use it will
> > have access to a simpler API.
> >
> The intention of this interface is very good, I like it, but
> I see one (more technical) problem here: the resolve() method
> is Environment or Request dependant. This means, if a component
> (e.g. the store) is contextualized at startup and gets the
> SystemContext, the resolving of resources must be done
> with the current environment in mind which might result in
> different resources.
> This resolving with respect to the current environment is
> of course necessary for all sitemap components (generators
> etc).
> If we get this working: +1
Ok, with that clarification, the resolve method would move to RequestContext.
> What do you mean with the org.apache.cocoon.environment.Context
> object? Is this the RequestContext mentioned below?
No, that is the equivalent of the ServletContext. It is global in scope,
and only a few components _really_ need it. If you need it, extend
Contextualizable, and cast the Context to SystemContext.
> > Lastly, this will also open up API optimizations in that we can
> > simplify the
> > signatures to setUp(RequestContext context, String source,
> > Parameters params);
> > If there is some new interface that needs to be supplied to the sitemap
> > components, it will be done through the RequestContext or
> > SystemContext objects
> > as is appropriate.
> >
> +1
>
> What about the Interface Cookie you mentioned above? I personally would
> like to clean up Request/Response interfaces.
> There are certainly Environments which do not use Cookies and for
> example don't know anything about headers. So I would like to separate
> them from the Request/Response so that one could test if the
> current environment supports this feature or not.
Hmm. If an environment doesn't support a feature, then it should
ignore it--in the case of headers. As to the Cookies--Cookies are
persistent client storage. Persistent in the fact that they can last
between sessions--not that they live forever (although sometimes it
seems like it).
In the cases where Cookies are not supported, we should follow the
standards of how Servlets handle the case when Cookies are turned
off. If there is no standard, we can throw a UnsupportedOperationException
or something similar. It would have to extend Runtime exception
though.
If you have specific API cleanups for Request/Response, we can go through
them as well. I was wanting to simplify the UI as much as possible
for the HEAD branch.
> By the way: About what timeframe and version are we talking here?
These are changes to HEAD. It should be done sooner than later so we
don't forget about them. But it is good for Cocoon 2.1. The arrangement
allows use to simply deprecate the unused methods and point users to
the real implementation. The deprecated methods should live for at least
a year--that way as projects naturally upgrade, they can move to the
new API. With the LogKit, we found that 5.5 months was not long enough
for projects to migrate.
P.S. This should not delay Cocoon 2.0 final.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Environment Revamping
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Berin Loritsch wrote:
>
> Currently, the Environment system has grown to provide an abstraction
> layer so that Cocoon logic can function equally well depending on whatever
> the environment is. This is a good thing, and in my opinion very
> necessary.
> However, what we have in our API can get confusing both for Cocoon app
> developers, and for environment adaptor providers.
>
> Because Cocoon began life as a Servlet, the environment is heavily slanted
> in that direction. While I do not want to reinvent the wheel that the
> servlet vendors have created, we can simplify our API so that app
> developers
> have an easier time. Currently, the Environment consists of the following
> interfaces:
>
> * Environment
> * Context
> * Cookie
> * Redirector
> * Request
> * Response
> * Session
> * Source
> * SourceResolver
>
> In addition to this we have the Avalon Context that we are using within
> the rest of the API for Cocoon system properties. Some of this is a bit
> much, and can be merged, and we can have a simpler API because of it.
> Granted that this would require deprecating some pieces in the HEAD
> branch of CVS, but I think we would be better for it in the long run.
> First, we have to consider what each piece is used for.
>
> INSTALLATION SPECIFIC API
> org.apache.avalon.framework.context.Context
> org.apache.cocoon.environment.Context
> SourceResolver
> Source
>
> SESSION SPECIFIC API
> Session
>
> REQUEST SPECIFIC API
> Redirector
> Request
> Response
> Map (ObjectModel)
>
> PERSISTENT CLIENT STORAGE
> Cookie
>
>
> In addition to all this, the ObjectModel is simply a Map that
> allows access
> to all of the APIs as we need them. It is clear that too many
> indirections
> (i.e. Maps) create a more cluttered API. What should we do then? Clearly
> there are two major categories of Context. There is the system
> context which
> provides meta information about the installation. Then there is
> the request
> specific context which allows us to pass information between stages, and
> access the session and client storage mechanisms.
>
> In order to simplify, I believe that there should be 2 Context objects to
> worry about: SystemContext and RequestContext. The SystemContext object
> would extend the AvalonContext--and be passed to any Contextualizable
> Component. So what would this look like:
>
> public interface SystemContext extends
> org.apache.avalon.framework.context.Context {
> Source resolve(String uri);
> org.apache.cocoon.environment.Context getEnvironmentContext();
> Object get(Object key); // from Avalon context
> }
>
> This removes the need for the SourceResolver interface to be
> exposed or passed
> as an argument to Components. Components that do not need it or
> use it will
> have access to a simpler API.
>
The intention of this interface is very good, I like it, but
I see one (more technical) problem here: the resolve() method
is Environment or Request dependant. This means, if a component
(e.g. the store) is contextualized at startup and gets the
SystemContext, the resolving of resources must be done
with the current environment in mind which might result in
different resources.
This resolving with respect to the current environment is
of course necessary for all sitemap components (generators
etc).
If we get this working: +1
What do you mean with the org.apache.cocoon.environment.Context
object? Is this the RequestContext mentioned below?
> The other Context woudl be the RequestContext. That API would be
> like this:
>
> public interface RequestContext extends Map {
> Request getRequest();
> Session getSession();
> Session getSession(boolean forceNew);
> Response getResponse();
> void redirect(String uri); // throws IllegalStateException if
> called after generator setup.
> Object get(Object key); // from Map
> void put(Object key, Object value); // from Map
> }
>
> This makes the RequestContext compatible with ObjectModel as it
> stands now--
> not forcing any MAJOR changes to the API. It also removes the
> need of exposing
> the Redirector interface to the clients as a passed argument.
> While it may
> seem tempting to do so, most developers will get the clue very
> quickly that
> it can only be done from the SetUp method. This will expose it
> to be used to
> generators and transformers alike, but the distinct difference is that the
> setup and generate commands are separate.
>
> This also simplifies client code--and the get/put methods in the
> RequestContext,
> but it also minimizes the overhead involved in looking up the
> specific environment
> interfaces from a generic Map.
>
> You'll notice that the Environment interface is missing. That is
> because the
> Environment interface has been identified as the contract between
> the sitemap
> and the environment that Cocoon is living in.
>
> Lastly, this will also open up API optimizations in that we can
> simplify the
> signatures to setUp(RequestContext context, String source,
> Parameters params);
> If there is some new interface that needs to be supplied to the sitemap
> components, it will be done through the RequestContext or
> SystemContext objects
> as is appropriate.
>
+1
What about the Interface Cookie you mentioned above? I personally would
like to clean up Request/Response interfaces.
There are certainly Environments which do not use Cookies and for
example don't know anything about headers. So I would like to separate
them from the Request/Response so that one could test if the
current environment supports this feature or not.
By the way: About what timeframe and version are we talking here?
Carsten
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org