cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: [C2]: ToDo - List for going Beta
Date Thu, 12 Apr 2001 11:50:32 GMT


On Thu, 12 Apr 2001, Carsten Ziegeler wrote:

> Hi,
>
> 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.

+1

> 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.

We have to take the following into acount for redirect:

1. If the pipeline has started to output characters onto the
   OutputStream IIRC the servlet engine will throw an Exception
   when issuing a redirect afterwards. There will be situation where you
   *never* will be able to redirect because of this restriction (think
   of a pipeline containing a XSP generator and an XMLSerializer which
   almost immediately produce output on the OutputStream).

2. If we allow redirects we then need a way to report that (probabbly by
   an Exception) to the pipeline from a sitemap component that a
   redirection has occurred to interrupt the resource production because
   it will throw an Exception otherwise.

> 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.

+1

> 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="..."/>
>       </error-notifiers>
>       and then
>     			<map:handle-errors type="error">
>     				<map:serialize status-code="500"/>
>    			</map:handle-errors>
>    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"/>
>    			</map:handle-errors>
>    If we agree on this, I will volunteer for it.

I've proposed this many many month ago. Stefano mentioned not to
over componentize the system. If we agree on componentizing the error
handler I'm +1 on a)

> 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.

+1

> 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.

For SVG as well!

>    I would like to extend the caching algorithm, to specify the Cacheable
>    interface even for Serializers and make a test implementation for the
>    FOPSerializer.
>    I think this is a nice to have but not required. But if I have enough
>    time I would like to test this.

+1024

Giacomo

> 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.
>
>
> Carsten
>
> Open Source Group                        sunShine - b:Integrated
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de                          mailto: cziegeler@sundn.de
> ================================================================
>
>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message