cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: [C2]: ToDo - List for going Beta
Date Thu, 12 Apr 2001 12:07:50 GMT
> Giacomo Pati wrote:
>
> 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.
>
Yes, I think, this is another reason for officially removing sendRedirect(). 
If really the only problem with sendRedirect() is migrating projects, we
could (and will) offer help on the migration.

> > 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)
> 
Oh, I didn't know that. It might be over componentization, but I found
many cases were I really wanted to have another ErrorNotifier and this
is currently not possible. We have configurable components everywhere,
if we count them (generators, transformers etc.) we have about eight
components which can be configured and only one (the ErrorNotifier)
which is not. So, this not really a reason over componentization.
So, let's vote about solution 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
> 
Hey, I thought you would like it...ok, perhaps if it snows at Easter I can
do it.

> 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


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message