cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject [RT] The API for the request object
Date Mon, 05 Jul 2004 07:06:07 GMT
Our request object is modelled after the request object of
the servlet spec. Now this approach is not bad, but Cocoon
has something which the servlet spec does not have: internal
requests. Unfortunately, our api does not take this into

The request has currently two methods for the URI:
 getRequestURI and getSitemapURI.

For external requests, getRequestURI returns the original
URI and getSitemapURI contains the part of the uri that has
entered the current sitemap. So these values differ as 
soon as you use sub sitemaps with removing the prefix.

Now, for internal requests the situation is not as good:
getRequestURI returns the uri of the original/external
request and getSitemapURI again contains the part of the
internal requests URI that has entered the current sitemap.
So, with internal requests you have no chance to get the
full internal URI as soon as you moved into a subsitemap.
This is imho bad.
Obviously, we can't change getRequestURI() for internal
requests as this would break compatibility.

One possibility would be to introduce a new method:
getSitemapPrefix() which returns the prefix for the current
sitemap, so this is the empty string for the main sitemap
and the prefix for sub sitemaps.

This would mean for external requests:
getRequestURI = getSitemapPrefix() + getSitemapURI()

and for internal requests:
URI of internal request = getSitemapPrefix() + getSitemapURI()

(We already have this prefix in the environemnt, so we just 
have to make it available).


We have a similar problem with attributes on the request object.
Currently the attributes are shared between external and internal
requests, making them "global".
So, an internal request can overwrite attributes of the external
request and of other internal requests. This can lead to serious
problems especially if you have several internal requests at the
same time using the same attribute - or if you want to process
internal requests in parallel.

Again, because of compatibility, we can't change this behaviour.
But we can extend it. Currently we have these methods for attributes
that work on global attributes:

setAttribute(String, Object)

We could add another set of methods that take an additional scope
parameter which is either "global" or "request" (like the portlet
api does for session attributes):

setAttribute(String, Object, int scope)
getAttribute(String, int scope)
getAttributeNames(int scope)
removeAttribute(String, int scope)

Our old method (without the scope) are simply an alias for the
new methods with the scope "global".

Cleanup of Attributes
Currently there is no nice way to cleanup some objects when the
processing is finished. This only works for components that are
pooled/recycled but not for data objects.

With 2.1.5 you could do this by adding a custom listener to the Cocoon
object and clean up. But this approach is not so nice as you can only
add one listener and you have to do it manually. And the listener
is not invoked for internal requests.

With Cocoon 2.1.x users have used the RequestLifecycle and
GlobalRequestLifecycle components that cleaned up the data
after the request has been processed. We deprecated these
components and removed them for 2.2.x. In general, the RL and GRL
components were a nice idea, but in most cases not the
component but the data should have been linked to a request,
so finding a better solution was a logical step.

At that time the basic idea was that the current RequestDataStore
component takes over this role, but it does't provide the cleanup
yet and it seems to be a little overkill for such a simple thing.
With the additional scope parameter for request attributes 
explained above, there is no need for a RequestDataStore component 

The only piece missing is cleaning up of data when the request
is finished. This feature has been requests in the last months
several times from users :)

Now, the basic mechanism for this could be to scan all attribute 
values of the request and find out if the value should be cleaned 
up or not. This could be done by either testing for the usual 
suspects from Avalon (Disposable, Recyclable) or by defining a 
new Cocoon specific interface.
But perhaps there is a better way?



View raw message