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
|