Re: [C3] Error handling in REST controller

(selectors for HTTP methods, serializers with status-code attributes). Anyways, there should be a clear contract between the sitemap and the REST controller, something like: * The REST controller is responsible for setting up the response, including error handling. * The handle-errors clause

[C3] Error handling in REST controller

ds, serializers with status-code attributes). Anyways, there should be a clear contract between the sitemap and the REST controller, something like: * The REST controller is responsible for setting up the response, including error handling. * The handle-errors clause kicks in if an erro

Re: error handling in aggregations

* Max Pfingsthorn: > Yes, this works well. I've tested it and with 'when="external"' > on 'map:handle-errors', it does stop the serializer from dumping > the data before the error page. Also, 'when="internal"' works > wonderfully inside the aggregate! > > I would be all for this change before

RE: error handling causes NPE? (was: error handling in aggregations)

nt me to a guide how to get the samples running in trunk? max > -Original Message- > From: Jean-Baptiste Quenot [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 22, 2006 16:54 > To: dev@cocoon.apache.org > Subject: Re: error handling causes NPE? (was: error handling in >

Re: error handling causes NPE? (was: error handling in aggregations)

* Max Pfingsthorn: > Yes, I'll change the one in trunk as well today. Hello Max, While you're at it, there's also the AbstractCachingProcessingPipeline that needs an update in trunk. TIA, -- Jean-Baptiste Quenot http://caraldi.com/jbq/

RE: error handling causes NPE? (was: error handling in aggregations)

nly place where a SitemapSource is used) releases everything correctly. Since this only seems to happen when an Exception is thrown during processing, I thought that maybe there is an error deeper in the error handling code. Something like a missing finally... The error is rather hard to noti

Re: error handling causes NPE? (was: error handling in aggregations)

Max Pfingsthorn schrieb: > Hi! > > Err, guys, can it be that the sources aren't released correctly after a > ProcessingException during pipeline execution? I get the same NPE I did when > I didn't release a sitemap source correctly a while ago after I apply this > patch to 2.1.8... > > Any ide

Re: error handling in aggregations

Jeremy Quinn wrote: Many thanks for the links Vadim !! You *are* welcome, you know. No need for double exclamation marks ;-P Vadim regards Jeremy On 20 Mar 2006, at 18:01, Vadim Gritsenko wrote: Jeremy Quinn wrote: On 20 Mar 2006, at 12:41, Bruno Dumon wrote: On Mon, 2006-03-20 at 12:

error handling causes NPE? (was: error handling in aggregations)

ginal Message- > From: Max Pfingsthorn > Sent: Tuesday, March 21, 2006 16:33 > To: dev@cocoon.apache.org > Subject: RE: error handling in aggregations > > > Hi! > > Yes, this works well. I've tested it and with > 'when="external"' on '

RE: error handling in aggregations

be all for this change before 2.1.9 comes out. If noone objects, I'll commit it within the hour. max > -Original Message- > From: Bruno Dumon [mailto:[EMAIL PROTECTED] > Sent: Sunday, March 19, 2006 14:33 > To: dev@cocoon.apache.org > Subject: Re: error handling in

Re: error handling in aggregations

Many thanks for the links Vadim !! regards Jeremy On 20 Mar 2006, at 18:01, Vadim Gritsenko wrote: Jeremy Quinn wrote: On 20 Mar 2006, at 12:41, Bruno Dumon wrote: On Mon, 2006-03-20 at 12:00 +, Jeremy Quinn wrote: Lets say the aggregation part that is in error, is a cocoon:// pipelin

Re: error handling in aggregations

Jeremy Quinn wrote: On 20 Mar 2006, at 12:41, Bruno Dumon wrote: On Mon, 2006-03-20 at 12:00 +, Jeremy Quinn wrote: Lets say the aggregation part that is in error, is a cocoon:// pipeline, it is possible that the called pipeline has it's own local error-handler . if this is the case,

Re: error handling in aggregations

On 20 Mar 2006, at 12:41, Bruno Dumon wrote: On Mon, 2006-03-20 at 12:00 +, Jeremy Quinn wrote: Thanks for your reply Bruno, On 19 Mar 2006, at 13:32, Bruno Dumon wrote: On Sun, 2006-03-19 at 12:10 +, Jeremy Quinn wrote: Hi All Investigating this further, I came up with this simpl

Re: error handling in aggregations

On Mon, 2006-03-20 at 12:00 +, Jeremy Quinn wrote: > Thanks for your reply Bruno, > > On 19 Mar 2006, at 13:32, Bruno Dumon wrote: > > > On Sun, 2006-03-19 at 12:10 +, Jeremy Quinn wrote: > >> Hi All > >> > >> Investigating this further, I came up with this simplest possible > >> sitemap

Re: error handling in aggregations

Thanks for your reply Bruno, On 19 Mar 2006, at 13:32, Bruno Dumon wrote: On Sun, 2006-03-19 at 12:10 +, Jeremy Quinn wrote: Hi All Investigating this further, I came up with this simplest possible sitemap to reproduce the problem : http://apache.org/cocoon/sitemap/1.0";>

Re: error handling in aggregations

On Sun, 2006-03-19 at 12:10 +, Jeremy Quinn wrote: > Hi All > > Investigating this further, I came up with this simplest possible > sitemap to reproduce the problem : > > > http://apache.org/cocoon/sitemap/1.0";> > > > > logger="sitemap.generator.file" pool-grow="4" pool

Re: error handling in aggregations

Hi All Investigating this further, I came up with this simplest possible sitemap to reproduce the problem : http://apache.org/cocoon/sitemap/1.0";> logger="sitemap.generator.file" pool-grow="4" pool-max="32" pool- min="4" src="org.apache.cocoon.generation.FileGenerator"/>

error handling in aggregations

Hi All I am working on a project that uses a lot of aggregations in the sitemap, using . My aggregated parts all call cocoon:// pipelines in other subsitemap, via the top level sitemap, where my top-level sitemap is not the one that comes built-in with Cocoon, but is my own, mounted direc

[jira] Created: (COCOON-1767) Error handling

Error handling -- Key: COCOON-1767 URL: http://issues.apache.org/jira/browse/COCOON-1767 Project: Cocoon Type: New Feature Components: - Blocks Framework Reporter: Reinhard Poetz There is sophisticated creation of error messages in the

Re: Refactored (again) XSLT error handling

Sylvain Wallez wrote: Sylvain Wallez wrote: Activating this second feature requires to change the XSLTProcessor implementation to o.a.c.c.xslt.XSLTProcessorImpl Damn! While porting to the 2.1 branch, I realized that this conflict with the same class that exists in the "deprecated" block.

Re: Refactored (again) XSLT error handling

Sylvain Wallez wrote: Ralph Goers wrote: Sylvain Wallez wrote: Sylvain Wallez wrote: Activating this second feature requires to change the XSLTProcessor implementation to o.a.c.c.xslt.XSLTProcessorImpl Damn! While porting to the 2.1 branch, I realized that this conflict with the same

Re: Refactored (again) XSLT error handling

Ralph Goers wrote: Sylvain Wallez wrote: Sylvain Wallez wrote: Activating this second feature requires to change the XSLTProcessor implementation to o.a.c.c.xslt.XSLTProcessorImpl Damn! While porting to the 2.1 branch, I realized that this conflict with the same class that exists in the

Re: Refactored (again) XSLT error handling

Sylvain Wallez wrote: Sylvain Wallez wrote: Activating this second feature requires to change the XSLTProcessor implementation to o.a.c.c.xslt.XSLTProcessorImpl Damn! While porting to the 2.1 branch, I realized that this conflict with the same class that exists in the "deprecated" block.

Re: Refactored (again) XSLT error handling

Sylvain Wallez wrote: Activating this second feature requires to change the XSLTProcessor implementation to o.a.c.c.xslt.XSLTProcessorImpl Damn! While porting to the 2.1 branch, I realized that this conflict with the same class that exists in the "deprecated" block. What do you think: is i

Refactored (again) XSLT error handling

Hi all, I refactored the error handling in TraxTransformer (again) and XSLTProcessor. * A usable We were used to have "Stylesheet directed termination" on screen, indicating we had to dig in the logs. We now have the message displayed, with location information. * XSLT c

DO NOT REPLY [Bug 32213] - Error handling and subsitemaps - errors not handled in subsitemap in special cases

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://issues.apache.org/bugzilla/show_bu

Re: Error Handling, him or me ???

Hi Sylvain > Well, error handlers have been reported to be working fine for years... Yes that's what I figured, > Is the page where this problem occurs the main request, or is there some > surrounding environment such as aggregation, cocoon: et al? no very basic error handler.it sends an xhtml se

Re: Error Handling, him or me ???

oceatoon wrote: Hi devers here again after not finding an answer in user, sorry. My problem concerns using It seems I must be doing something wrong, because on a simple not-found exeption, everything goes great...hmmm...he finds the file(error.html) I give in sitemap...but then when I visit a prop

Error Handling, him or me ???

Hi devers here again after not finding an answer in user, sorry. My problem concerns using It seems I must be doing something wrong, because on a simple not-found exeption, everything goes great...hmmm...he finds the file(error.html) I give in sitemap...but then when I visit a proper page the err

Re: [VOTE] Internal Pipelines Error Handling

Sylvain Wallez wrote: Yep. And that shows that it's really a feature of and not of . Ok, deal! :-) Patch landed in SVN, includes samples - take a look... Vadim

Re: [VOTE] Internal Pipelines Error Handling

s really a feature of and not of . Isn't FS? What would be the scenario for having error handler for internal but not external requests? Maybe a scenario where you want to have errors be handled by the servlet engine? When attribute is missing or set to false, error handling

Re: [VOTE] Internal Pipelines Error Handling

on map:pipelines, if that feature is needed at all. Isn't FS? What would be the scenario for having error handler for internal but not external requests? When attribute is missing or set to false, error handling behaviour is as it is currently. Limitation of current implementation of the

Re: [VOTE] Internal Pipelines Error Handling

Vadim Gritsenko wrote: Hi All, I'd implemented error handling for internal pipelines which allows to discard content generated by the internal pipeline and replace it instead with the content generated by the error-handler of the internal pipeline. This feature is activated only when pip

Re: [VOTE] Internal Pipelines Error Handling

... [X ] Let's include this feature into 2.1.7 release! ... [ X] Single error handler is just what we need. No too sure about this but why not start simpler and expand if use-cases show the need for hierarchical handling [ ] No, it must support hierarchical error handling. -Ber

[VOTE] Internal Pipelines Error Handling

Hi All, I'd implemented error handling for internal pipelines which allows to discard content generated by the internal pipeline and replace it instead with the content generated by the error-handler of the internal pipeline. This feature is activated only when pipeline has an attribut

Re: error handling

Due to time constraints I worked around it and lowered the priority on my TODO list. Feel free to take over :-) I'd love to. But since I have only glanced at the sitemap processing I have a feeling it will be a hack. Also, I'm up to my eyeballs trying to figure out what Pluto has in mind with Po

Re: error handling

Torsten Curdt said: > Ralph Goers wrote: >> There was quite a discussion here regarding this, the last posted >> message >> of which seems to be >> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108670415314132&w=2. >> Was >> anything ever done about this? We are running into problems with this

Re: error handling

Ralph Goers wrote: There was quite a discussion here regarding this, the last posted message of which seems to be http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108670415314132&w=2. Was anything ever done about this? We are running into problems with this in the Portal. Due to time constraints

RE: error handling

ter said: >> >> Torsten Curdt <[EMAIL PROTECTED]> asks: >> >> > After further investigations it seems like exceptions >> > are passed to the error handler inside the treeprocessor. >> > But requests using the cocoon protcol don't go through >> >

DO NOT REPLY [Bug 32213] New: - Error handling and subsitemaps - errors not handled in subsitemap in special cases

gzilla/show_bug.cgi?id=32213 Error handling and subsitemaps - errors not handled in subsitemap in special cases Summary: Error handling and subsitemaps - errors not handled in subsitemap in special cases Product: Cocoon 2 Version: Current S

Re: error handling

errors=true", but it will handle errors occuring during the _building_ of the pipeline, and not during its _execution_. That's not what I am after. It does not help for error handling on aggregation. We should aim for the execution time. It all depends where the errors occur in the aggreg

RE: error handling

rs=true", but it will handle errors occuring > > during the _building_ of the pipeline, and not during its > _execution_. > > That's not what I am after. It does not help for error > handling on aggregation. We should aim for the execution time. > Yepp, execution

Re: error handling

nd "?cocoon:handle-errors=true", but it will handle errors occuring during the _building_ of the pipeline, and not during its _execution_. That's not what I am after. It does not help for error handling on aggregation. We should aim for the execution time. Handling errors occuring d

Re: error handling

Torsten Curdt wrote: ...What about... our current behaviour would be "external". I would like to have "always" andt the "internal" option might be FS ;) +1 for the declaration, looks clean enough! Carsten, I'd really like to takle this ASAP. We are currently using a *very* ugly work around. S

Re: error handling

our current behaviour would be "external". I would like to have "always" andt the "internal" option might be FS ;) +1 for the declaration, looks clean enough! Carsten, I'd really like to takle this ASAP. We are currently using a *very* ugly work around. Yes, yes, do it - you don't have to wai

RE: error handling

Torsten Curdt wrote: > > >> ...What about... > >> > >> > >> > >> our current behaviour would be "external". > >> I would like to have "always" andt the "internal" option > might be FS > >> ;) > > > > > > +1 for the declaration, looks clean enough! > > Carsten, I'd really like to takle thi

RE: error handling

Vadim Gritsenko <[EMAIL PROTECTED]> writes: > > Hunsberger, Peter wrote: > > >Vadim Gritsenko <[EMAIL PROTECTED]> writes: > > > > > ... > > >>Now, if > >>you want to > >>change current default, you'll have to add this attribute. > >> > >> > > > >Now that seems like FS to me... > > > > No

Re: error handling

Hunsberger, Peter wrote: Vadim Gritsenko <[EMAIL PROTECTED]> writes: ... Now, if you want to change current default, you'll have to add this attribute. Now that seems like FS to me... No, it's called "backward compatibility" ;-) Vadim

RE: error handling

rnal" option might be FS ;) > >> > >> > > > >Hmmm, just wondering, if I have: > > > > > > > >and I define a > > > > > > > >within it, would that now work? And if it did, would I have

Re: error handling

work? And if it did, would I have to specify handle-errors="internal" or would that be the default for such a pipeline? I realize, most people would likely only want a single handle-errors section so that you don't have to specify the same error handling in two different place

RE: error handling

and I define a within it, would that now work? And if it did, would I have to specify handle-errors="internal" or would that be the default for such a pipeline? I realize, most people would likely only want a single handle-errors section so that you

Re: error handling

...What about... our current behaviour would be "external". I would like to have "always" andt the "internal" option might be FS ;) +1 for the declaration, looks clean enough! Carsten, I'd really like to takle this ASAP. We are currently using a *very* ugly work around. WDYT? cheers -- Torsten

Re: error handling

Le 4 juin 04, à 09:59, Torsten Curdt a écrit : ...What about... our current behaviour would be "external". I would like to have "always" andt the "internal" option might be FS ;) +1 for the declaration, looks clean enough! -Bertrand

Re: error handling

I think we can use the available things. We discussed two solutions: specifying it at the call, like: cocoon:handle-error:/something or cocoon:/something?cocoon:handle-error=true Uaaahh maybe the first one - but this looks dead ugly and feels more like hack for what should be the default. ...or

RE: error handling

Carsten Ziegeler dijo: > Are you talking about 2.1.5 or CVS Head? CVS Head has a rewritten > internal request handling that simply might have bugs, so we have > to fix these bugs first before its really usable. Yep.!!! it tortures now for 2 days now! :( Best Regards, Antonio Gallardo

RE: error handling

are no objections. > > But where to place it? I reckon we either need to make the > interal pipeline calls go through the same hook inside the > treeprocessor or move the error handling further down into > the pipeline code. > I think we can use the available things. We discussed two solu

RE: error handling

Antonio Gallardo wrote: > > Carsten Ziegeler dijo: > > Vadim Gritsenko wrote: > > > >> > >> IIRC, last first friday we had a chat with Carsten about adding an > >> attribute to the or to the which will > >> indicate what behavior is needed in case of internal > request: throw > >> exceptio

Re: error handling

are no objections. But where to place it? I reckon we either need to make the interal pipeline calls go through the same hook inside the treeprocessor or move the error handling further down into the pipeline code. WDYT? cheers -- Torsten

RE: error handling

Carsten Ziegeler dijo: > Vadim Gritsenko wrote: > >> >> IIRC, last first friday we had a chat with Carsten about >> adding an attribute to the or to the >> which will indicate what behavior is needed in >> case of internal request: throw exception or process >> . Carsten? >> > Yes, nothing of tha

RE: error handling

Vadim Gritsenko wrote: > > IIRC, last first friday we had a chat with Carsten about > adding an attribute to the or to the > which will indicate what behavior is needed in > case of internal request: throw exception or process > . Carsten? > Yes, nothing of that is implemented yet. The dis

Re: error handling

Torsten Curdt wrote: I have an interal pipeline which sometimes throws an exception due to broken links. And another one using it --> calls the intenal pipeline ... Using the first pipeline works just fine. Exceptions are being caught and

RE: error handling

same way as external ones. > > So basically error handling is missing - or broken for > > such internal requests. > > > > I think this is a vital feature and I am > > wondering why noone hit that before. > > We came across this and I had assumed it was intentio

RE: error handling

Torsten Curdt <[EMAIL PROTECTED]> asks: > After further investigations it seems like exceptions > are passed to the error handler inside the treeprocessor. > But requests using the cocoon protcol don't go through > the treeprocessor the same way as external ones. > So b

Re: error handling

After further investigations it seems like exceptions are passed to the error handler inside the treeprocessor. But requests using the cocoon protcol don't go through the treeprocessor the same way as external ones. So basically error handling is missing - or broken for such internal reques

Re: error handling

I have an interal pipeline which sometimes throws an exception due to broken links. And another one using it --> calls the intenal pipeline ... ...of course We were discussing it here... does the cocoon protoco

error handling

I have an interal pipeline which sometimes throws an exception due to broken links. And another one using it --> calls the intenal pipeline ... Using the first pipeline works just fine. Exceptions are being caught and a default xml file is

Re: Sample "error handling" shows a blank page

Vadim Gritsenko dijo: > Antonio Gallardo wrote: > >>Here is another sample with problem. It show an blank page: >> >>http://localhost:/samples/errorhandling/exception/exception?exception=error >> >> > > That's intentional, AFAIR. At least under Tomcat - that's Tomcat's > behavior in case of Err

Re: Sample "error handling" shows a blank page

Antonio Gallardo wrote: Here is another sample with problem. It show an blank page: http://localhost:/samples/errorhandling/exception/exception?exception=error That's intentional, AFAIR. At least under Tomcat - that's Tomcat's behavior in case of Error. I don't remember how it works with Je

Sample "error handling" shows a blank page

Hi: Here is another sample with problem. It show an blank page: http://localhost:/samples/errorhandling/exception/exception?exception=error Best Regards, Antonio Gallardo