cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject [C2]: ToDo - List for going Beta
Date Thu, 12 Apr 2001 07:06:53 GMT

in addition to the current ToDo-List I would like to discuss the following
points which I find important for the beta. I think we should very quickly
agree on this points, if they are useful or if they are just overkill, so
that we can implement them in the next week or leave them for another release.
Most of them have been discussed in the last weeks, but we haven't had any
final result for them.

1. Creating wrappers for Session and Cookie
   The creation of these wrapper classes would allow us to be independent
   of the javax.servlet classes.
   As discussed earlier this week this is very useful.
   If we agree on this, I will volunteer for it.

2. Cleaning up the environment
   We had the recent discussion about the sendRedirect() method of the
   Response object (same applies to the getRealPath() of the Context).
   The discussion about sendRedirect() showed, that most of us agreed
   to remove it from the Request object. But the main problem then
   would be porting existing applications from C1 to C2. If we leave
   sendRedirect() only for porting reasion, everybody will use it, and
   we have no chance to remove it at a later time.
   My suggestion is to remove the sendRedirect() from the Request. For 
   porting reasion the HttpRequest still contains the sendRedirect(),
   thus casting the Request to the HttpRequest will allow the call
   the method. This will only work in the http environment, but for me 
   this sounds reasonable for a fast migration.
   There are others methods in the environment which should be removed
   for same reasons as the sendRedirect().
   If we agree on this, I will volunteer for it.

3. Synchron sitemap reloading
   As I explained earlier this week, the asynchron reloading of the
   sitemap is a nice feature but not suitable for development.
   I would suggest adding a configuration parameter for cocoon to
   specify if the reloding is asynchron or synchron.
   If we agree on this, I will volunteer for it.

4. ErrorNotifier
   The "error-pipeline" has a fixed ErrorNotifier. This is not customizable
   like the other components in the sitemap. For an easier error handling
   I would suggest a pluggable system.
   There a two easy possibilities:
   a) Configuration of all ErrorNotifiers like all other components, e.g.
      the generators. This would lead to a configuration part:
      <error-notifiers default="error">
          <error-notifier name="error" src="..."/>
      and then
    			<map:handle-errors type="error">
    				<map:serialize status-code="500"/> 
   b) The ErrorNotifier currently used is the default and it is possible
      to specify another class with the handle-errors tag:
    			<map:handle-errors src="...myclass..">
    				<map:serialize status-code="500"/> 
   If we agree on this, I will volunteer for it.

5. Reloading of jar-files
   The class-path for the Cocoon-Servlet is only build once when the servlet
   is initialised. If you want to deploy other jar files you have to restart
   the servlet. A reloading of the Cocoon is not sufficient. This is not
   very convenient. Suggestion: When Cocoon is reloaded (a new cocoon instance
   is created then) the classpath is rebuild and used.

6. Caching of StreamPipelines
   The current caching algorithm caches only the event pipeline. For FOP it
   would be very nice to cache the whole response.
   I would like to extend the caching algorithm, to specify the Cacheable
   interface even for Serializers and make a test implementation for the 
   I think this is a nice to have but not required. But if I have enough
   time I would like to test this.

So I think we should quickly discuss this, add the remaining points to
the ToDo-List, search volunteers (if not already found...) and implement them
asap as the 1st of may is approaching.

If you have any other points for the ToDo, comments, etc. please let us 
discuss them now.


Open Source Group                        sunShine - b:Integrated
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn                          mailto: 

To unsubscribe, e-mail:
For additional commands, email:

View raw message