DO NOT REPLY [Bug 12562] New: - handle-errors skipped after first transformation

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_b

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/source SourceHandlerImpl.java XMLDBSource.java XMLDBSourceFactory.java

cziegeler2002/09/11 23:16:43 Modified:src/java/org/apache/cocoon/components/source/impl FileSource.java URLFactoryWrapper.java SourceFactoryWrapper.java src/java/org/apache/cocoon/components/source So

Big problems with JispFilesystemStore

Hi, the JispFilesystemStore has some serious problems/bugs - it does not implement the free() or the keys() method! - So if you use this store for caching (and it's the default) your cache might grow and grow - because the store janitor cannot free it!!! So, I recommend not to use the JispFilesys

RE: Cocoon running modes (was Re: Error Handling is NOT working)

Might be worth investigating into running modes. Hmm. But comming back to the original problem ;) - We already have an intermediate output stream implemented and noone really complained about it: Its the buffered output stream in the abstract text serializer...the only problem here is that a) the

RE: cvs commit: xml-cocoon2/src/java/org/apache/cocoon Cocoon.java

Sylvain Wallez wrote: > > > > In the above case, it is starting to throw something, so it's ok, and > > even good, that something is logged. > > It's not the exception being logged, but the event that will cause the > > exception to be thrown. > > > That's exactly what I mean. > > Carsten,

Re: Cocoon running modes (was Re: Error Handling is NOT working)

While generally a good idea, different operational modes would make more sense when Cocoon 2.1 enters a stable stage. If we introduce modes early on, then everything that we add in the development cycle will have to be tested twice - once in each mode. Ivelin - Original Message - From:

Re: Error Handling is NOT working

Maybe I did not explain clearly what I meant. SAX processing is extremely valuable and it should not be compromised. And in fact it does not have to be. Here is a simple suggestion. What if we wrap the Cocoon servlet with another filter servlet? This way the J2EE container (Servlets 2.3 compati

RE: [control flow] names and concepts [was: changes and new sample]

> Ola Berg wrote: > > Personally, I like either \"flow\" and \"use-flow\" or > \"director\" and \"direct\". On second thougt \"flow\" and > \"use-flow\" is what I like best. (Part of the problem is > that \"flow\" can be used both as a noun (the component) and > as a verb (the action). \"use-flow

Re: Hello. I'd like to contribute to coccon

- Original Message - From: "Nicola Ken Barozzi" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 11, 2002 11:57 AM Subject: Re: Hello. I'd like to contribute to coccon > fud more wrote: Sorry for using my Alias. my name is Ritesh. ;^> > > Hello Everybody. > > > >

RE: Error Handling is NOT working

Torsten wrote: > Guys, isn't it obvious we cannot realy provide errors in a > user friendly > manner since we are delivering the page on-the-fly via SAX? > Buffering the > whole page seems to reduce the positve aspects we get from > using SAX and we > get closer to Cocoon1. > > Maybe we should ha

Re: Hello. I'd like to contribute to coccon

fud more wrote: > Hello Everybody. > > I downloaded cocoon a few months ago. I experimented with web page creation > with cocoon, and found that cocoon does provide a clear separation between > logic and view. I am interested in learning about the internals of cocoon as > well as contributing to

Re: [control flow] changes and new sample

Ivelin Ivanov wrote: > > I have been following along the thread silently trying to finally "get" the > picture. > > At this point, the only reasonable question that I can ask is, > if it is possible to consider providing the continuation capabilities within > the Actions instead of promoting Jav

Re: [control flow] names and concepts [was: changes and new sample]

Ola Berg wrote: > > Brainstorm > > 1) What component is it that we speak of? > > flow > controller > flow-controller > director > flow-director > > This defines an application flow > > > > > > A \"director\" in a play makes the actors act according to a script, it could work: > > >

Re: [control flow] changes and new sample

Ovidiu Predescu wrote: > > On Monday, September 9, 2002, at 05:41 AM, Sylvain Wallez wrote: > > > Stefano Mazzocchi wrote: > > > > > > > >> I know it would be easier *right now* to name it 'controller' and > >> forget > >> about all the above, but I ask you to think in 5 years from now, then >

Hello. I'd like to contribute to coccon

Hello Everybody. I downloaded cocoon a few months ago. I experimented with web page creation with cocoon, and found that cocoon does provide a clear separation between logic and view. I am interested in learning about the internals of cocoon as well as contributing to your efforts in developing

Re: Cocoon running modes (was Re: Error Handling is NOT working)

> Is this buffer size only related to development ? I don't think so. Well, of course not necessarily... but at least I wouldn't want this burden that will definitly mean a drop of performance and worse scaleability for our deployed system. The question is: for what type of user do we creat

Re: [control flow] changes and new sample

Hi Sylvain, Sylvain Wallez wrote: > Christopher Oliver wrote: > > >Hi Ivelin, > > > >Actually I believe it is possible to have continuations in pure Java -- > >using bytecode rewriting -- however this approach is quite intrusive and its > >effect on performance and code-size is not insignificant

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/transformation I18nTransformer.java

sylvain 2002/09/11 08:23:40 Modified:src/java/org/apache/cocoon/transformation I18nTransformer.java Log: Reset also strBuffer. This caused some problems when reusing a transformer after an error inside an i18n element. Revision ChangesPath 1.23

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/transformation I18nTransformer.java

sylvain 2002/09/11 08:23:26 Modified:src/java/org/apache/cocoon/transformation Tag: cocoon_2_0_3_branch I18nTransformer.java Log: Reset also strBuffer. This caused some problems when reusing a transformer after an error inside an i18n element. Revision

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/url ContextURLFactory.java

sylvain 2002/09/11 08:22:23 Modified:src/java/org/apache/cocoon/components/url ContextURLFactory.java Log: Log an info instead of an error : applications may test for the existence. Revision ChangesPath 1.7 +2 -2 xml-cocoon2/src/java/o

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/url ContextURLFactory.java

sylvain 2002/09/11 08:21:57 Modified:src/java/org/apache/cocoon/components/url Tag: cocoon_2_0_3_branch ContextURLFactory.java Log: Log an info instead of an error : applications may test for the existence. Revision ChangesPath No

Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon Cocoon.java

Nicola Ken Barozzi wrote: > > Sylvain Wallez wrote: > >> [EMAIL PROTECTED] wrote: >> >>> cziegeler2002/09/11 03:08:36 >>> >>> >> >> >>> Index: ActionSetNodeBuilder.java >>> === >>> RCS file: >>> >/home/cvs/xml-cocoon2/src

Re: Brakes (was: [control flow] changes and new sample)

Tim Coninx wrote: >Hello, > >As I was pointed by a friend to the previous thread, I noticed a >proposal to prototype Brakes, which I have been working on a time ago. > >This is not a commercial message, but a status report of the technology. > >Brakes consists of two parts: >- A bytecode transfor

Cocoon running modes (was Re: Error Handling is NOT working)

Torsten Curdt wrote: > > >Guys, isn't it obvious we cannot realy provide errors in a user friendly >manner since we are delivering the page on-the-fly via SAX? Buffering the >whole page seems to reduce the positve aspects we get from using SAX and we >get closer to Cocoon1. > >Maybe we should

RE: Error Handling is NOT working

> -Original Message- > From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, September 11, 2002 4:04 PM > To: [EMAIL PROTECTED] > Subject: Re: Error Handling is NOT working > > > > Torsten Curdt wrote: > > > > > > Guys, isn't it obvious we cannot realy provide errors in

Re: Error Handling is NOT working

Torsten Curdt wrote: > > > Guys, isn't it obvious we cannot realy provide errors in a user friendly > manner since we are delivering the page on-the-fly via SAX? Buffering the > whole page seems to reduce the positve aspects we get from using SAX and we > get closer to Cocoon1. > > Maybe we

DO NOT REPLY [Bug 12532] - [PATCH] FLOW

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_b

Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon Cocoon.java

Sylvain Wallez wrote: > [EMAIL PROTECTED] wrote: > >> cziegeler2002/09/11 03:08:36 >> >> > > >> Index: ActionSetNodeBuilder.java >> === >> RCS file: >> >/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/treepr

DO NOT REPLY [Bug 12532] New: - [PATCH] FLOW

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_b

Re: Error Handling is NOT working

Guys, isn't it obvious we cannot realy provide errors in a user friendly manner since we are delivering the page on-the-fly via SAX? Buffering the whole page seems to reduce the positve aspects we get from using SAX and we get closer to Cocoon1. Maybe we should have two different modes to ru

Re: Error Handling is NOT working

Michael Melhem wrote: >On Wed, Sep 11, 2002 at 01:53:01PM +0200, Carsten Ziegeler wrote: > > >>Nicola Ken Barozzi wrote: >> >> >>>Carsten, do what you want, I'm really fed up with error handling. >>>I'll start to complain myself now, let's see if it helps. >>> >>> >>> >>So I count thi

Re: Error Handling is NOT working

Carsten Ziegeler wrote: >Sylvain Wallez wrote: > > >>Ivelin Ivanov wrote: >> >> >> >>>- Original Message - >>>From: "Sylvain Wallez" <[EMAIL PROTECTED]> >>>To: <[EMAIL PROTECTED]> >>>Sent: Wednesday, September 11, 2002 8:01 AM >>>Subject: Re: Error Handling is NOT working >>> >>> >>

Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon Cocoon.java

[EMAIL PROTECTED] wrote: >cziegeler2002/09/11 03:08:36 > > > Index: ActionSetNodeBuilder.java > === > RCS file: >/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/treeprocessor/sitemap/ActionSetNodeBuilder.java,

RE: Error Handling is NOT working

Sylvain Wallez wrote: > > Ivelin Ivanov wrote: > > >- Original Message - > >From: "Sylvain Wallez" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]> > >Sent: Wednesday, September 11, 2002 8:01 AM > >Subject: Re: Error Handling is NOT working > > > > > >>Why does have a serializer to flush it

Re: Error Handling is NOT working

Nicola Ken Barozzi wrote: > > Sylvain Wallez wrote: > >> Ivelin Ivanov wrote: >> >>> - Original Message - >>> From: "Sylvain Wallez" <[EMAIL PROTECTED]> >>> To: <[EMAIL PROTECTED]> >>> Sent: Wednesday, September 11, 2002 8:01 AM >>> Subject: Re: Error Handling is NOT working >>> >>> >>>

Re: Error Handling is NOT working

Sylvain Wallez wrote: > Ivelin Ivanov wrote: > >> - Original Message - >> From: "Sylvain Wallez" <[EMAIL PROTECTED]> >> To: <[EMAIL PROTECTED]> >> Sent: Wednesday, September 11, 2002 8:01 AM >> Subject: Re: Error Handling is NOT working >> >> >>> Why does have a serializer to flush its

Re: Error Handling is NOT working

Ivelin Ivanov wrote: >- Original Message - >From: "Sylvain Wallez" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Wednesday, September 11, 2002 8:01 AM >Subject: Re: Error Handling is NOT working > > >>Why does have a serializer to flush its output when it is recycled ? >>Flushing

Re: Error Handling is NOT working

- Original Message - From: "Sylvain Wallez" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 11, 2002 8:01 AM Subject: Re: Error Handling is NOT working > > Why does have a serializer to flush its output when it is recycled ? > Flushing (and output stream management)

Re: Error Handling is NOT working

Ivelin Ivanov wrote: > I agree with Carsten. The output should be flushed to the real output stream > only after the sitemap processing has ended. Since the *original* Cocoon design document, having output come out right away because of the SAX processing was regarded as a *big feature*, becau

Re: Error Handling is NOT working

Carsten Ziegeler wrote: >Hi, > >I just have to repeat an email I wrote over a year ago, because the >problem is getting worse: > >If an error occurs in the pipeline, the error handler is called and >produces some output (or a response). At this time, the original >pipeline could have already outp

Re: Error Handling is NOT working

+1 I didn't realize we're voting yet. - Original Message - From: "Carsten Ziegeler" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 11, 2002 6:53 AM Subject: RE: Error Handling is NOT working > > Nicola Ken Barozzi wrote: > > > > Carsten, do what you want, I'm

Re: Error Handling is NOT working

I agree with Carsten. The output should be flushed to the real output stream only after the sitemap processing has ended. Allowing direct access to the output stream proved to be very problematic for JSP applications as well. The 2.3 filters were warmly welcomed in the JSP world. The one big is

BSF (Bean Scripting Framework) and Cocoon's usage of it ?? (Re: Seeking help on BSF calling a non-Java language engine (Rexx) ...

Hi there, a couple of days ago I posted a question regarding the Bean Scripting Framework's (BSF) usage of Cocoon. BSF allows Java programs to invoke functions/scripts/programs written in non-Java languages and originates in an IBM alphawork project. In the past months a process has taken pla

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/generation AbstractServerPage.java

sylvain 2002/09/11 05:44:10 Modified:.changes.xml src/java/org/apache/cocoon/acting SessionPropagatorAction.java src/java/org/apache/cocoon/components/language/generator ProgramGeneratorImpl.java

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/generation AbstractServerPage.java

sylvain 2002/09/11 05:43:58 Modified:.Tag: cocoon_2_0_3_branch changes.xml src/java/org/apache/cocoon/acting Tag: cocoon_2_0_3_branch SessionPropagatorAction.java src/java/org/apache/cocoon/components/language/generator

Re: Error Handling is NOT working

Carsten Ziegeler wrote: > Nicola Ken Barozzi wrote: > >>Carsten Ziegeler wrote: >> >>>Nicola Ken Barozzi wrote: >>> >>> Carsten, do what you want, I'm really fed up with error handling. I'll start to complain myself now, let's see if it helps. >>> >>>So I count this as a +10. Thanks.

Re: [control flow] changes and new sample

How about callbacks. Instead of doing sendpage( pageName ) and expecting the flow to continue on the next line, we could use sendPage ( pageName, callbackMethodPointer ) This way we avoid the need to suspend threads. However if we consider this option, then how about simply using event handlers

RE: Error Handling is NOT working

Nicola Ken Barozzi wrote: > > Carsten Ziegeler wrote: > > Nicola Ken Barozzi wrote: > > > >>Carsten, do what you want, I'm really fed up with error handling. > >>I'll start to complain myself now, let's see if it helps. > >> > > > > So I count this as a +10. Thanks. > > It's a +1000 to have y

Re: Error Handling is NOT working

Carsten Ziegeler wrote: > Nicola Ken Barozzi wrote: > >>Carsten, do what you want, I'm really fed up with error handling. >>I'll start to complain myself now, let's see if it helps. >> > > So I count this as a +10. Thanks. It's a +1000 to have you write that code. A -1000 for ranting. We know

Re: Error Handling is NOT working

On Wed, Sep 11, 2002 at 01:53:01PM +0200, Carsten Ziegeler wrote: > > Nicola Ken Barozzi wrote: > > > > Carsten, do what you want, I'm really fed up with error handling. > > I'll start to complain myself now, let's see if it helps. > > > So I count this as a +10. Thanks. IIRC, there was also so

Sourcewriter problem on JBoss / Jetty 3.0.2

Hi, I have a problem with the sourcewritingtransformer on jboss / jetty. The problem is in org.apache.cocoon.webapps.session.xml.XMLUtil -> getFirstNodeFromPath() The code that is trying to find the first node calls "item.getLocalName().equals()". The call to item.getLocalName() returns nu

RE: Error Handling is NOT working

Nicola Ken Barozzi wrote: > > Carsten, do what you want, I'm really fed up with error handling. > I'll start to complain myself now, let's see if it helps. > So I count this as a +10. Thanks. Carsten - To unsubscribe, e-mail:

Brakes (was: [control flow] changes and new sample)

Hello, As I was pointed by a friend to the previous thread, I noticed a proposal to prototype Brakes, which I have been working on a time ago. This is not a commercial message, but a status report of the technology. Brakes consists of two parts: - A bytecode transformer adds bytecode after ever

Re: Error Handling is NOT working

Carsten Ziegeler wrote: > Hi, > > I just have to repeat an email I wrote over a year ago, because the > problem is getting worse: > > If an error occurs in the pipeline, the error handler is called and > produces some output (or a response). At this time, the original > pipeline could have alre

Error Handling is NOT working

Hi, I just have to repeat an email I wrote over a year ago, because the problem is getting worse: If an error occurs in the pipeline, the error handler is called and produces some output (or a response). At this time, the original pipeline could have already output some information and you might

cvs commit: xml-cocoon2/src/java/org/apache/cocoon Cocoon.java

cziegeler2002/09/11 03:08:36 Modified:src/java/org/apache/cocoon/components/treeprocessor/sitemap ActionSetNodeBuilder.java PipelineNodeBuilder.java CallNodeBuilder.java SelectNodeBuilder.java RedirectToNodeBuilder.

Re: [control flow] changes and new sample

On 9 Sep 2002 at 21:20, Ivelin Ivanov wrote: > ... > At this point, the only reasonable question that I can ask is, > if it is possible to consider providing the continuation capabilities within > the Actions instead of promoting JavaScript as another language supported by > Cocoon. > ... I have

Re: [control flow] changes and new sample

Christopher Oliver wrote: >Hi Ivelin, > >Actually I believe it is possible to have continuations in pure Java -- >using bytecode rewriting -- however this approach is quite intrusive and its >effect on performance and code-size is not insignificant (see: >http://www.cs.kuleuven.ac.be/~tim/MOS/bra

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/acting ServerPagesAction.java RequestParameterExistsAction.java SessionInvalidatorAction.java SessionPropagatorAction.java ResourceExistsAction.java SessionStateAction.java ScriptAction.java SessionIsValidAction.java SessionValidatorAction.java RequestParamAction.java SendmailAction.java

cziegeler2002/09/11 01:26:45 Modified:src/java/org/apache/cocoon/acting ServerPagesAction.java RequestParameterExistsAction.java SessionInvalidatorAction.java SessionPropagatorAction.java Res