You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@sundn.de> on 2001/04/12 09:06:53 UTC
[C2]: ToDo - List for going Beta
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.
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="..."/>
</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.
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
FOPSerializer.
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.
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
Re: [C2]: ToDo - List for going Beta
Posted by giacomo <gi...@apache.org>.
On Thu, 12 Apr 2001, Sylvain Wallez wrote:
>
>
> giacomo a �crit :
> >
> <snip/>
> > 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).
> >
> The OutputStream is buffered : according to servlet 2.2 Javadoc, calling
> HttpServletResponse.sendRedirect will throw an IllegalStateException "if
> the response has been commited", which means the buffer size has been
> exceeded and some data has been actually sent back to the client
> browser. The exact moment when this occurs depends of course on the
> buffer size (see ServletResponse javadoc).
>
> In our Cocoon 1 apps, the application code that issues redirects (after
> performing what would now be Actions) is at the very beginning of XSPs,
> so there's a high probability that the buffer will not be flushed when
> redirects occurs (IIRC, I even read once that Tomcat fully buffers the
> output).
Well, to be honest there are too many whens and ifs. Even if Tomcat if
fully buffering the output (which is a bad thing IMO).
> I know and agree that redirect in the pipeline is a bad thing, but we
> really would like to easily port our C1 apps to C2...
I know and understand that rerdirect in C1 in a used pattern (because
there is no choice) but I really would like to keep C2 without that
functionality to keep the clean model we have but will help with
guidelines and support on how to migrate to C2 instead.
Giacomo
>
> > 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.
> >
> <snip/>
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
>
> ---------------------------------------------------------------------
> 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
Re: [C2]: ToDo - List for going Beta
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
giacomo a écrit :
>
<snip/>
> 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).
>
The OutputStream is buffered : according to servlet 2.2 Javadoc, calling
HttpServletResponse.sendRedirect will throw an IllegalStateException "if
the response has been commited", which means the buffer size has been
exceeded and some data has been actually sent back to the client
browser. The exact moment when this occurs depends of course on the
buffer size (see ServletResponse javadoc).
In our Cocoon 1 apps, the application code that issues redirects (after
performing what would now be Actions) is at the very beginning of XSPs,
so there's a high probability that the buffer will not be flushed when
redirects occurs (IIRC, I even read once that Tomcat fully buffers the
output).
I know and agree that redirect in the pipeline is a bad thing, but we
really would like to easily port our C1 apps to C2...
> 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.
>
<snip/>
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: ToDo - List for going Beta
Posted by giacomo <gi...@apache.org>.
On Thu, 12 Apr 2001, [iso-8859-1] J�rg Prante wrote:
> Am Donnerstag, 12. April 2001 14:07 schrieb Carsten Ziegeler:
> > > > 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.
>
> Hi everyone!
>
> The sendRedirect() is also used in URI-based session generation. Why is this
> important? The situation is when cookies are disabled at the client side and
> the servlet engine generates a new session ID for tracking a session in a
> cookie-less mode.
This is the concern of the servlet engine and is transparent to any
servlet IIRC.
> The URI will not change to include the ID, but a
> sendRedirect() to the same page will make the ID visible in a single request.
> If Cocoon 2 gets detached from the servlet API logic, we need to think about
> a suitable connection to outer session tracking environments to enable this.
>
> I am still thinking about a sitemap-controlled session framework for Cocoon
> 2, together with a Cocoon 2 site reporting application. After the change
> proposed here, it looks like Cocoon 2 will need a private URI encoder for
> URI-based session tracking. But session ID generators are usually located
> outside of Cocoon. How can we incorporate externally created session IDs into
> Cocoon 2?
We never said that you don't have access to vital functionallity of the
environments objects only that those get wrapped with own Interfaces.
>
> In session.xsl, which comes from Cocoon 1, some time ago I added some
> features using HttpResponse.encodeURL(). Also,
> HttpResponse.encodeRedirectURL() is important for session tracking. This must
> also be considered for the rework.
I don't see why the encodeURL() should be hidden. It doesn't alter
anything of the model (in contrary to the sendRedirect).
> I'm hoping that you agree that such a session tracking feature should be
> nice in Cocoon 2? Or should it be delayed for Cocoon 3 ;-) ? Should Cocoon
> 2 be able to connect seamlessly to a HTTP session engine if such a session
> engine is present? Then we might consider something like a
> "SessionTrackingConnector" to Tomcat 4.
Well, would you like to make a proposal?
Giacomo
>
> J�rg
>
> --
> J�rg Prante
> Sevenval AG (HRB 32757) e-business marketing technologies
> D-50667 K�ln . Alter Markt 36-42
> Fon +49 221 65007-0 . Fax 4249891
> http://www.sevenval.de . joerg@7val.com
>
> ---------------------------------------------------------------------
> 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
Re: AW: [C2]: ToDo - List for going Beta
Posted by Jörg Prante <jo...@7val.com>.
Am Donnerstag, 12. April 2001 14:07 schrieb Carsten Ziegeler:
> > > 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.
Hi everyone!
The sendRedirect() is also used in URI-based session generation. Why is this
important? The situation is when cookies are disabled at the client side and
the servlet engine generates a new session ID for tracking a session in a
cookie-less mode. The URI will not change to include the ID, but a
sendRedirect() to the same page will make the ID visible in a single request.
If Cocoon 2 gets detached from the servlet API logic, we need to think about
a suitable connection to outer session tracking environments to enable this.
I am still thinking about a sitemap-controlled session framework for Cocoon
2, together with a Cocoon 2 site reporting application. After the change
proposed here, it looks like Cocoon 2 will need a private URI encoder for
URI-based session tracking. But session ID generators are usually located
outside of Cocoon. How can we incorporate externally created session IDs into
Cocoon 2?
In session.xsl, which comes from Cocoon 1, some time ago I added some
features using HttpResponse.encodeURL(). Also,
HttpResponse.encodeRedirectURL() is important for session tracking. This must
also be considered for the rework.
I'm hoping that you agree that such a session tracking feature should be
nice in Cocoon 2? Or should it be delayed for Cocoon 3 ;-) ? Should Cocoon
2 be able to connect seamlessly to a HTTP session engine if such a session
engine is present? Then we might consider something like a
"SessionTrackingConnector" to Tomcat 4.
J�rg
--
J�rg Prante
Sevenval AG (HRB 32757) e-business marketing technologies
D-50667 K�ln . Alter Markt 36-42
Fon +49 221 65007-0 . Fax 4249891
http://www.sevenval.de . joerg@7val.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: ToDo - List for going Beta
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 4:14 PM +0200 12/4/01, giacomo wrote:
>On Thu, 12 Apr 2001, Jeremy Quinn wrote:
>
>> At 2:07 PM +0200 12/4/01, Carsten Ziegeler wrote:
[snip]
>> >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.
>>
>> This is a really nice offer, but it is slightly more complicated ....
>>
>> The issue as it effects me is that if redirection is available, then the
>> authoring language that we use to build webApps (the Crudlet.org TagLib)
>> will contain the concept of redirection. If redirection was not available,
>> the language would have been designed quite differently.
>>
>> I am at the stage where I am about to re-implement the language Crudlet.org
>> 2.0, this has been in specification for a while. Now I know that
>> redirection is not going to be available in C2 from the TagLib level, I
>> have the chance to hopefully re-design certain aspects of the language so
>> then used in C1, it will use the response taglib for re-direction, while in
>> C2 that will be mapped in the sitemap.
>>
>> Problem is, I understand so little about the capabilities of the Sitemap at
>> this stage.
>>
>> I would love to have a discussion to help me understand the correct way of
>> implementing the Crudlet webApp, but don't want to drag you away from the
>> amazing work that you are doing!
>
>It seems that I have to play the devils advocate today :)
>
>Talking about me I'm probabbly at the same stage as you. I don't know
>about the capabilities of the Crudlet webApp.
It is based on Beans which connect to JavaSpace-based Primitives.
It comes with a set of standard JINI Services for maintaining the Space
(de/archive to SQL, manifest maintenance, mailing, exchange, encryption
etc.) and a standard set of Beans for compound data types (UserBean,
OrganisationBean, MoneyBean, DateBean, ExchangeBean etc. etc.)
It handles a standard set of Events on Beans (create, retrieve, update,
delete, lifecycle, exists, template).
We use it for building a reinsurance trading application
http://www.risk2risk.com.
BTW. Sun want to use Crudlet (hence Cocoon) for jini.org (!)
I suspect the published documentation is a little behind, though you might
like to look at http://www.crudlet.org, it is published under the Sun
Community Lisence.
>But one is for sure: We've never said to kill Cocoon 1, so this option
>remains for those apps which migration effort is too costly.
I think I know now how to redesign the Crudlet 2.0 TagLib so it can use
response:send-redirect in Cocoon 1, but rely on sitemap redirection in
Cocoon 2.
I am really glad this issue came up when it did, as I am just about to
start implementing the new version!
I wish I had more time to understand how it would be best to deploy Crudlet
in Cocoon 2 before the re-write, but I've been asked to get on with it
straight away, oh well! I just hope I am not writing myself into a hole ....
Sorry for moaning before thinking ;)
BTW. Is Stefano's FlowMap idea likely to get implemented?
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: ToDo - List for going Beta
Posted by giacomo <gi...@apache.org>.
On Thu, 12 Apr 2001, Jeremy Quinn wrote:
> At 2:07 PM +0200 12/4/01, Carsten Ziegeler wrote:
> >> > 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.
>
> This is a really nice offer, but it is slightly more complicated ....
>
> The issue as it effects me is that if redirection is available, then the
> authoring language that we use to build webApps (the Crudlet.org TagLib)
> will contain the concept of redirection. If redirection was not available,
> the language would have been designed quite differently.
>
> I am at the stage where I am about to re-implement the language Crudlet.org
> 2.0, this has been in specification for a while. Now I know that
> redirection is not going to be available in C2 from the TagLib level, I
> have the chance to hopefully re-design certain aspects of the language so
> then used in C1, it will use the response taglib for re-direction, while in
> C2 that will be mapped in the sitemap.
>
> Problem is, I understand so little about the capabilities of the Sitemap at
> this stage.
>
> I would love to have a discussion to help me understand the correct way of
> implementing the Crudlet webApp, but don't want to drag you away from the
> amazing work that you are doing!
It seems that I have to play the devils advocate today :)
Talking about me I'm probabbly at the same stage as you. I don't know
about the capabilities of the Crudlet webApp.
But one is for sure: We've never said to kill Cocoon 1, so this option
remains for those apps which migration effort is too costly.
Giacomo
>
>
> regards Jeremy
>
>
>
> --
> ___________________________________________________________________
>
> Jeremy Quinn Karma Divers
> webSpace Design
> HyperMedia Research Centre
>
> <ma...@mac.com> <http://www.media.demon.co.uk>
> <phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
>
> ---------------------------------------------------------------------
> 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
Re: AW: [C2]: ToDo - List for going Beta
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 2:07 PM +0200 12/4/01, Carsten Ziegeler wrote:
>> > 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.
This is a really nice offer, but it is slightly more complicated ....
The issue as it effects me is that if redirection is available, then the
authoring language that we use to build webApps (the Crudlet.org TagLib)
will contain the concept of redirection. If redirection was not available,
the language would have been designed quite differently.
I am at the stage where I am about to re-implement the language Crudlet.org
2.0, this has been in specification for a while. Now I know that
redirection is not going to be available in C2 from the TagLib level, I
have the chance to hopefully re-design certain aspects of the language so
then used in C1, it will use the response taglib for re-direction, while in
C2 that will be mapped in the sitemap.
Problem is, I understand so little about the capabilities of the Sitemap at
this stage.
I would love to have a discussion to help me understand the correct way of
implementing the Crudlet webApp, but don't want to drag you away from the
amazing work that you are doing!
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[C1] Xerces 1 bug affects Cocoon...
Posted by Per Kreipke <pe...@onclave.com>.
I sent the following to the xerces-j-dev list but am concerned that any
update wouldn't work with C1. Is anyone using Xerces 1.3.X with C1? How
could this change get incorporated into Xerces and then into Cocoon (e.g.
does anyone here have commit privileges on Xerces too)?
Per.
Snippet..................................
In class ElementImpl, in the function normalize(), the following code can
throw an exception if a null node value returned.
...
// If kid is empty, remove it
if ( kid.getNodeValue().length()==0 )
removeChild( kid );
...
Not sure what the proper change is:
if (null != kid.getNodeValue() && kid.getNodeValue().length() == 0)
removeChild( kid );
is probably correct but perhaps not, I don't know the DOM well enough to
say.
[Cocoon note: The normalize() code is called from xsp-java.xsl as the last
step before generating the page's data model.]
The bug can be reproduced by creating a node as follows:
property = document.createElement("test");
property.appendChild(document.createTextNode(null));
element.appendChild(property);
Specifically, any number of functions in XSPRequestLibrary.java will cause
the exception. For example, if a form is posted using method GET, the
content type is null and XSPRequestLibrary.getContentType() produces an
'invalid' node. Or, if cookies are set incorrectly, the following in Cocoon
causes an exception:
XSPCookieLibrary.getDomain()....
property = document.createElement("cookie:domain");
property.appendChild(document.createTextNode(cookie.getDomain()));
element.appendChild(property);
Thoughts?
Per Kreipke
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: ToDo - List for going Beta
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
On Thursday 12 April 2001 14:31, you wrote:
> 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.
<snip/>
> > > > 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.)
Hi everyone! :)
It's a long time since I've written to this list, I missed you all :-P
I've been very busy on a WYSIWY...hopefully;)G editor for XML (using XSL),
now I'm sweating into beta.
Anyway, having written the ErrorNotifier stuff I would like to explain
briefly why it's done that way.
As you can guess I started out thinking of a component for error reporting,
but Stefano talked me out of it, and I think he is right.
Errors are not IMHO "content", but system messages.
Because of this there is no need to generate a different DTD for any kind of
error... imagine having 20 different DTDs for errors and keeping track of all
the stylesheet that go with them... ;)
So I decided to stick to a fixed DTD that can deliver not just errors but
messages. The DTD (implied) has some fixed tags that give it a type,a name
and short descriptions; after that a series of added tags for possible new
data to expose. This is NOT fixed. :)
In fact I decided to create an interface for notifications. If your
component-code-whatever throws an Exception which implements also this
interface the ErrorNotifier reads the extra descriptions-data and appends
them to the XML.
So you have a fixed DTD with the content you need. IMO this is flexible
enough.
I also wanted to make this thing resilient, so if it understands that it
needs to output html directly because cocoon will not process further it does
so; in C1 I had a tough problem with error messages coming out not correctly
(difficult to read) because cocoon hadn't yet started up.
So, now that I explained it (I think I should have done it before ;) ) do you
think it could be ok?
Or maybe you all knew this and I didn't get the point ;-P
If this is comprehensible, can someone put it in the docs please?
If you need a rewrite tell me.
Ciao,
nicola_ken
PS: Can someone finally take away that TODO about hardcoded errors that made
me write this stuff in the first place! :-)) (I can't believe it's still
there!)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: ToDo - List for going Beta
Posted by giacomo <gi...@apache.org>.
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
AW: [C2]: ToDo - List for going Beta
Posted by Carsten Ziegeler <cz...@sundn.de>.
> 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
Re: [C2]: ToDo - List for going Beta
Posted by giacomo <gi...@apache.org>.
On Sat, 14 Apr 2001, Donald Ball wrote:
> On Fri, 13 Apr 2001, giacomo wrote:
>
> > > > 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).
> > >
> > > actually, apparantly, that's not strictly true with tomcat (and other
> > > 2.2+ servlet engines?) - if the bytes that have been written to the
> > > outputstream have not been flushed yet, then it is still possible to send
> > > redirects and set http response headers.
> >
> > Is this something reliable?
>
> yes. you can get and set the buffer size too. craig or pier could probably
> say more about it if you want the nitty gritty. personally, i'd say we
> should allow sendRedirect and try to accomplish it by checking isCommited
> and resetting the response buffer if possible, and if not to just keep
> going. put a big warning in the docs about how this is chancy if you try
> to use it after you've starting spitting out any significant amount of
> output and leave it at that. sound good?
Well, Donald, that's only Tomcat. How about all the other servlet
engines. That was what I meant by "reliable".
> i'm going to be an unhappy camper if my xsp pages can't issue redirects.
I believe you are too deeply in C1 thinking to need the capability to
redirect from an XSP page :)
I appologies if some of you think I'd like to be a dictator. I'm
definitely not. But I see many of you thinking in C1 terms and because I
almost never work with C1 but only with C2 I really don't see many
things proposed to be in C2 are good patterns/practice. I can also see
that some of you like to go over to C2 with existing C1 apps and thus
want to have it as cheep as possible. But I tell you if you or your
customers are not willing to pay the price to do it the C2 way than
staying with C1 will be still an option and I think than it is
the right option (and thus you don't have any porting costs than).
I don't think C2 is only an enhanced C1. It's definitely a different
beast.
Of course I can't stop anyone implemeting it but I definitely won't do
it and I will take care that there are big letters warning every one
using it and I don't give any support to people having troubles with
it (except to show them the way I think is correct :)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: ToDo - List for going Beta
Posted by Donald Ball <ba...@webslingerZ.com>.
On Fri, 13 Apr 2001, giacomo wrote:
> > > 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).
> >
> > actually, apparantly, that's not strictly true with tomcat (and other
> > 2.2+ servlet engines?) - if the bytes that have been written to the
> > outputstream have not been flushed yet, then it is still possible to send
> > redirects and set http response headers.
>
> Is this something reliable?
yes. you can get and set the buffer size too. craig or pier could probably
say more about it if you want the nitty gritty. personally, i'd say we
should allow sendRedirect and try to accomplish it by checking isCommited
and resetting the response buffer if possible, and if not to just keep
going. put a big warning in the docs about how this is chancy if you try
to use it after you've starting spitting out any significant amount of
output and leave it at that. sound good?
i'm going to be an unhappy camper if my xsp pages can't issue redirects.
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: ToDo - List for going Beta
Posted by giacomo <gi...@apache.org>.
On Thu, 12 Apr 2001, Donald Ball wrote:
> On Thu, 12 Apr 2001, giacomo wrote:
>
> > 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).
>
> actually, apparantly, that's not strictly true with tomcat (and other
> 2.2+ servlet engines?) - if the bytes that have been written to the
> outputstream have not been flushed yet, then it is still possible to send
> redirects and set http response headers.
Is this something reliable?
> there's a method you can use to
> check - response.isCommitted().
>
> oh, and what about content aggregation? i'd think that'd be on the todo
> list.
BTW it is already on the todo list
Giacomo
>
> - donald
>
>
> ---------------------------------------------------------------------
> 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
Re: [C2]: ToDo - List for going Beta
Posted by giacomo <gi...@apache.org>.
On Thu, 12 Apr 2001, Donald Ball wrote:
> On Thu, 12 Apr 2001, giacomo wrote:
>
> > 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).
>
> actually, apparantly, that's not strictly true with tomcat (and other
> 2.2+ servlet engines?) - if the bytes that have been written to the
> outputstream have not been flushed yet, then it is still possible to send
> redirects and set http response headers. there's a method you can use to
> check - response.isCommitted().
>
> oh, and what about content aggregation? i'd think that'd be on the todo
> list.
Yes (see my commits from today, the rest will come next week I hope :)
Giacomo
>
> - donald
>
>
> ---------------------------------------------------------------------
> 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
Re: [C2]: ToDo - List for going Beta
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 12 Apr 2001, giacomo wrote:
> 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).
actually, apparantly, that's not strictly true with tomcat (and other
2.2+ servlet engines?) - if the bytes that have been written to the
outputstream have not been flushed yet, then it is still possible to send
redirects and set http response headers. there's a method you can use to
check - response.isCommitted().
oh, and what about content aggregation? i'd think that'd be on the todo
list.
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: ToDo - List for going Beta
Posted by giacomo <gi...@apache.org>.
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