cocoon-dev mailing list archives

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


On Thu, 12 Apr 2001, Carsten Ziegeler wrote:

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

Another good thing about componentized Errornotifier is that the
<pipeline> element becomes more sense. You can have different error
handler for a group of uris which have different management/monitoring
needs (send mails, SMS, JMX  etc. etc.)

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

Yes. We had the problem with performance on the e-shop we've build
because in the first version we've made all the images from text in a db
table. Afterwards we've put a reverse proxy server in front of C2 to
speed up those image serving. But definitely a cached serializer will be
the next step toward a high performance system :)

Giacomo

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


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


Mime
View raw message