You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ola Berg <ol...@arkitema.se> on 2002/09/05 11:29:37 UTC
3 suggestions
Being a user of the Cocoon XML-publishing feature, I have not thought of any improvements in the web-app/flowscript area.
But here are some random thougths. The first two, I have to implement real soon.
1) XML directory generator
Given a dir
dir/
doc1.xml
doc2.xml
Where doc1 and doc2 contains a <title> element:
<doc>
<title>Document <number>1</number></title>
...
</doc>
I would like to write this in the sitemap:
<map:generate type=\"xml-directory\" src=\"file:/path/to/dir\" xpath=\"/doc/title\"/>
and get this from the serializer
<dir:directory name=\"dir\" lastModified=\"1026478615000\" date=\"7/12/02 2:56 PM\" requested=\"true\">
�<dir:file name=\"doc1.xml\" lastModified=\"1010746920000\" date=\"1/11/02 12:02 PM\" content=\"Document 1\"/>
�<dir:file name=\"doc2.xml\" lastModified=\"1010746920000\" date=\"1/11/02 12:02 PM\" content=\"Document 2\"/>
</dir:directory>
Maybe one could do it more elaborate passing through markup in the extracted document snippet (using namespaces)
<dir:file name=\"doc1.xml\" ...>
Document <a:number>1</a:number>
</dir:file>
2) Lousy HTML. At work there are legacy web apps where bad HTML is generated by bad old scripts. In an attempt to XML-ize and automate, we need to be able to handle the lousy HTML. But even with a site map that says:
<map:generate src=\"hello.html\" type=\"html\"/>
<map:serialize type=\"xhtml\"/>
the tidy can\'t even handle
<html>
<body>
<h1>Hello, world!</H1>
Hi there.
<p>
This is plain wrong.
<p>
But it works in certain browsers
</body>
</html>
...and the \"html\" I need to handle is worse than that.
3) src-path in the exceptions from the parsers
As it stands, it is difficult to determine which of the sources in a pipe that the parser compains about. Isn\'t it possible to wrap the exceptions so that info on what part of the process that did fail?
/O
--------------------
ola.berg@arkitema.se
0733 - 99 99 17
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: 3 suggestions
Posted by Steven Noels <st...@outerthought.org>.
Ola Berg wrote:
> Being a user of the Cocoon XML-publishing feature, I have not thought
> of any improvements in the web-app/flowscript area.
>
> But here are some random thougths. The first two, I have to implement
> real soon.
>
> 1) XML directory generator
>
> Given a dir
>
> dir/ doc1.xml doc2.xml
>
> Where doc1 and doc2 contains a <title> element:
>
> <doc> <title>Document <number>1</number></title> ... </doc>
>
> I would like to write this in the sitemap:
>
> <map:generate type=\"xml-directory\" src=\"file:/path/to/dir\"
> xpath=\"/doc/title\"/>
>
> and get this from the serializer
>
> <dir:directory name=\"dir\" lastModified=\"1026478615000\"
> date=\"7/12/02 2:56 PM\" requested=\"true\"> <dir:file
> name=\"doc1.xml\" lastModified=\"1010746920000\" date=\"1/11/02 12:02
> PM\" content=\"Document 1\"/> <dir:file name=\"doc2.xml\"
> lastModified=\"1010746920000\" date=\"1/11/02 12:02 PM\"
> content=\"Document 2\"/> </dir:directory>
>
> Maybe one could do it more elaborate passing through markup in the
> extracted document snippet (using namespaces)
>
> <dir:file name=\"doc1.xml\" ...> Document <a:number>1</a:number>
> </dir:file>
Have a look at the XPathDirectoryGenerator in Cocoon, or Libre in
Forrest (http://outerthought.net/forrest/libre-intro.html)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Make errors caught only by Cocoon.java
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Thu, Sep 05, 2002 at 04:10:49PM +0200, Carsten Ziegeler wrote:
>
> Nicola Ken Barozzi wrote:
> > >
> > > if (getLogger().isDebugEnabled()) {
> > > getLogger().debug(.....);
> > > }
> > >
> > > to save logging un-logged text ?
> >
> > We should *always* do it, it is common practice... when we remember to
> > do it ;-)
> >
>
> And we vote several times on this - every time with the same agreement that
> we do it this way, but there had noone time to fix this in all places.
> So, as a new committer.... ;)
*smile* :)
> Carsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [VOTE] Make errors caught only by Cocoon.java
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
> >
> > if (getLogger().isDebugEnabled()) {
> > getLogger().debug(.....);
> > }
> >
> > to save logging un-logged text ?
>
> We should *always* do it, it is common practice... when we remember to
> do it ;-)
>
And we vote several times on this - every time with the same agreement that
we do it this way, but there had noone time to fix this in all places.
So, as a new committer.... ;)
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Make errors caught only by Cocoon.java
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Marcus Crafter wrote:
> Hi All,
>
> Hope all is well.
>
> +1 from me too, although with the example below, I'd use warn() or
> something appropriate to indicate that an exceptional situation
> has occured (unless that exception really was just for debugging).
>
> Shouldn't we also wrap our logging statements with tests before
> hand ?
>
> ie. instead of:
>
> getLogger().debug("some value " + value + ", some other value " + v);
>
> have:
>
> if (getLogger().isDebugEnabled()) {
> getLogger().debug(.....);
> }
>
> to save logging un-logged text ?
We should *always* do it, it is common practice... when we remember to
do it ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Make errors caught only by Cocoon.java
Posted by Giacomo Pati <gi...@apache.org>.
On Thu, 5 Sep 2002, Marcus Crafter wrote:
> Hi All,
>
> Hope all is well.
>
> +1 from me too, although with the example below, I'd use warn() or
> something appropriate to indicate that an exceptional situation
> has occured (unless that exception really was just for debugging).
>
> Shouldn't we also wrap our logging statements with tests before
> hand ?
>
> ie. instead of:
>
> getLogger().debug("some value " + value + ", some other value " + v);
>
> have:
>
> if (getLogger().isDebugEnabled()) {
> getLogger().debug(.....);
> }
This should be normal practice since long ago. LogKit is fast but given
the amount of debug messages Cocoon produces we should use that
coding pattern everywhere.
Giacomo
>
> to save logging un-logged text ?
>
> Cheers,
>
> Marcus
>
> On Thu, Sep 05, 2002 at 03:51:12PM +0200, Carsten Ziegeler wrote:
> > OK, then +1
> >
> > Carsten
> >
> > > -----Original Message-----
> > > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > > Sent: Thursday, September 05, 2002 3:36 PM
> > > To: cocoon-dev@xml.apache.org
> > > Subject: Re: [VOTE] Make errors caught only by Cocoon.java
> > >
> > >
> > >
> > > Carsten Ziegeler wrote:
> > > >
> > > >>-----Original Message-----
> > > >>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > > >>Sent: Thursday, September 05, 2002 3:24 PM
> > > >>To: cocoon-dev@xml.apache.org
> > > >>Subject: [VOTE] Make errors caught only by Cocoon.java
> > > >>
> > > >>
> > > >>I would really like to see the errors caught ONLY by Cocoon.java, and
> > > >>logged there. It would reduce the problems we are having a LOT.
> > > >>
> > > >>+1
> > > >>
> > > >
> > > > I would like to extend this proposal a little bit by:
> > > >
> > > > "Exceptions are only logged when they are consumed (and not rethrown)".
> > > >
> > > > So, if I write
> > > > try {
> > > > ...
> > > > } catch (Exception e) {
> > > > // ignore this...
> > > > }
> > > >
> > > > this should be logged, perhaps not with level error, but debug.
> > >
> > > +1 Yes, that's it.
> > >
> > > --
> > > Nicola Ken Barozzi nicolaken@apache.org
> > > - verba volant, scripta manent -
> > > (discussions get forgotten, just code remains)
> > > ---------------------------------------------------------------------
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Make errors caught only by Cocoon.java
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
Hi All,
Hope all is well.
+1 from me too, although with the example below, I'd use warn() or
something appropriate to indicate that an exceptional situation
has occured (unless that exception really was just for debugging).
Shouldn't we also wrap our logging statements with tests before
hand ?
ie. instead of:
getLogger().debug("some value " + value + ", some other value " + v);
have:
if (getLogger().isDebugEnabled()) {
getLogger().debug(.....);
}
to save logging un-logged text ?
Cheers,
Marcus
On Thu, Sep 05, 2002 at 03:51:12PM +0200, Carsten Ziegeler wrote:
> OK, then +1
>
> Carsten
>
> > -----Original Message-----
> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > Sent: Thursday, September 05, 2002 3:36 PM
> > To: cocoon-dev@xml.apache.org
> > Subject: Re: [VOTE] Make errors caught only by Cocoon.java
> >
> >
> >
> > Carsten Ziegeler wrote:
> > >
> > >>-----Original Message-----
> > >>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > >>Sent: Thursday, September 05, 2002 3:24 PM
> > >>To: cocoon-dev@xml.apache.org
> > >>Subject: [VOTE] Make errors caught only by Cocoon.java
> > >>
> > >>
> > >>I would really like to see the errors caught ONLY by Cocoon.java, and
> > >>logged there. It would reduce the problems we are having a LOT.
> > >>
> > >>+1
> > >>
> > >
> > > I would like to extend this proposal a little bit by:
> > >
> > > "Exceptions are only logged when they are consumed (and not rethrown)".
> > >
> > > So, if I write
> > > try {
> > > ...
> > > } catch (Exception e) {
> > > // ignore this...
> > > }
> > >
> > > this should be logged, perhaps not with level error, but debug.
> >
> > +1 Yes, that's it.
> >
> > --
> > Nicola Ken Barozzi nicolaken@apache.org
> > - verba volant, scripta manent -
> > (discussions get forgotten, just code remains)
> > ---------------------------------------------------------------------
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Make errors caught only by Cocoon.java
Posted by Ivelin Ivanov <iv...@apache.org>.
+1 for
> >> "Exceptions are only logged when they are consumed (and not rethrown)".
----- Original Message -----
From: "Vadim Gritsenko" <va...@verizon.net>
To: <co...@xml.apache.org>
Sent: Thursday, September 05, 2002 8:54 AM
Subject: Re: [VOTE] Make errors caught only by Cocoon.java
> Nicola Ken Barozzi wrote:
>
> >
> > Carsten Ziegeler wrote:
> >
> >>
> >>> -----Original Message-----
> >>> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> >>> Sent: Thursday, September 05, 2002 3:24 PM
> >>> To: cocoon-dev@xml.apache.org
> >>> Subject: [VOTE] Make errors caught only by Cocoon.java
> >>>
> >>>
> >>> I would really like to see the errors caught ONLY by Cocoon.java, and
> >>> logged there. It would reduce the problems we are having a LOT.
> >>>
> >>> +1
> >>>
> >>
> >> I would like to extend this proposal a little bit by:
> >
>
> Same here... Minor correction:
>
> >> "Exceptions are only logged when they are consumed (and not rethrown)".
> >>
> >> So, if I write
> >> try {
> >> ...
> >> } catch (Exception e) {
> >> // ignore this...
> >> }
> >>
> >> this should be logged, perhaps not with level error, but debug.
> >
>
> And perharps without stacktrace. It is meaningless in 99.9% situations
> to log, i.e., FileNotFoundException's stacktrace.
>
>
> >>
> >
> > +1 Yes, that's it.
>
>
> +1
>
>
> Vadim
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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: [VOTE] Make errors caught only by Cocoon.java
Posted by Vadim Gritsenko <va...@verizon.net>.
Nicola Ken Barozzi wrote:
>
> Carsten Ziegeler wrote:
>
>>
>>> -----Original Message-----
>>> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>> Sent: Thursday, September 05, 2002 3:24 PM
>>> To: cocoon-dev@xml.apache.org
>>> Subject: [VOTE] Make errors caught only by Cocoon.java
>>>
>>>
>>> I would really like to see the errors caught ONLY by Cocoon.java, and
>>> logged there. It would reduce the problems we are having a LOT.
>>>
>>> +1
>>>
>>
>> I would like to extend this proposal a little bit by:
>
Same here... Minor correction:
>> "Exceptions are only logged when they are consumed (and not rethrown)".
>>
>> So, if I write
>> try {
>> ...
>> } catch (Exception e) {
>> // ignore this...
>> }
>>
>> this should be logged, perhaps not with level error, but debug.
>
And perharps without stacktrace. It is meaningless in 99.9% situations
to log, i.e., FileNotFoundException's stacktrace.
>>
>
> +1 Yes, that's it.
+1
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [VOTE] Make errors caught only by Cocoon.java
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
OK, then +1
Carsten
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Thursday, September 05, 2002 3:36 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [VOTE] Make errors caught only by Cocoon.java
>
>
>
> Carsten Ziegeler wrote:
> >
> >>-----Original Message-----
> >>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> >>Sent: Thursday, September 05, 2002 3:24 PM
> >>To: cocoon-dev@xml.apache.org
> >>Subject: [VOTE] Make errors caught only by Cocoon.java
> >>
> >>
> >>I would really like to see the errors caught ONLY by Cocoon.java, and
> >>logged there. It would reduce the problems we are having a LOT.
> >>
> >>+1
> >>
> >
> > I would like to extend this proposal a little bit by:
> >
> > "Exceptions are only logged when they are consumed (and not rethrown)".
> >
> > So, if I write
> > try {
> > ...
> > } catch (Exception e) {
> > // ignore this...
> > }
> >
> > this should be logged, perhaps not with level error, but debug.
>
> +1 Yes, that's it.
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> 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: [VOTE] Make errors caught only by Cocoon.java
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
>
>>-----Original Message-----
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>Sent: Thursday, September 05, 2002 3:24 PM
>>To: cocoon-dev@xml.apache.org
>>Subject: [VOTE] Make errors caught only by Cocoon.java
>>
>>
>>I would really like to see the errors caught ONLY by Cocoon.java, and
>>logged there. It would reduce the problems we are having a LOT.
>>
>>+1
>>
>
> I would like to extend this proposal a little bit by:
>
> "Exceptions are only logged when they are consumed (and not rethrown)".
>
> So, if I write
> try {
> ...
> } catch (Exception e) {
> // ignore this...
> }
>
> this should be logged, perhaps not with level error, but debug.
+1 Yes, that's it.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [VOTE] Make errors caught only by Cocoon.java
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Thursday, September 05, 2002 3:24 PM
> To: cocoon-dev@xml.apache.org
> Subject: [VOTE] Make errors caught only by Cocoon.java
>
>
> I would really like to see the errors caught ONLY by Cocoon.java, and
> logged there. It would reduce the problems we are having a LOT.
>
> +1
>
I would like to extend this proposal a little bit by:
"Exceptions are only logged when they are consumed (and not rethrown)".
So, if I write
try {
...
} catch (Exception e) {
// ignore this...
}
this should be logged, perhaps not with level error, but debug.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[VOTE] Make errors caught only by Cocoon.java
Posted by Nicola Ken Barozzi <ni...@apache.org>.
I would really like to see the errors caught ONLY by Cocoon.java, and
logged there. It would reduce the problems we are having a LOT.
+1
Carsten Ziegeler wrote:
> Nicola Ken Barozzi wrote:
>
>
>
>>>But there was no consensus on if we should log when the
>>
>>exception is thrown
>>
>>>or when it is catched and consumed (and not rethrown). I prever the last
>>>way and someone else prefered the first solution. So, it's still as it
>>>is and you get an exception logged more than once - blowing up the log.
>>
>>It should be logged when it is consumed, because you can never tell if
>>you catch a new exception or an already rethrown one.
>>
>>BTW, do we really need to log exceptions in the components?
>>
>>I would really like to see the errors caught ONLY by Cocoon.java, and
>>logged there. It would reduce the problems we are having a LOT.
>>
>
> That's what I suggested years ago...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: 3 suggestions
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
> >
> > But there was no consensus on if we should log when the
> exception is thrown
> > or when it is catched and consumed (and not rethrown). I prever the last
> > way and someone else prefered the first solution. So, it's still as it
> > is and you get an exception logged more than once - blowing up the log.
>
> It should be logged when it is consumed, because you can never tell if
> you catch a new exception or an already rethrown one.
>
> BTW, do we really need to log exceptions in the components?
>
> I would really like to see the errors caught ONLY by Cocoon.java, and
> logged there. It would reduce the problems we are having a LOT.
>
That's what I suggested years ago...
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: 3 suggestions
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Nicola Ken Barozzi wrote:
>
>>Carsten Ziegeler wrote:
>>
>>>>-----Original Message-----
>>>>From: ola.berg@arkitema.se [mailto:ola.berg@arkitema.se]
>>>>Sent: Thursday, September 05, 2002 11:30 AM
>>>>To: cocoon-dev@xml.apache.org
>>>>Subject: 3 suggestions
>>>>
>>>>
>>>>3) src-path in the exceptions from the parsers
>>>>
>>>>As it stands, it is difficult to determine which of the sources
>>>>in a pipe that the parser compains about. Isn\'t it possible to
>>>>wrap the exceptions so that info on what part of the process that
>>>>did fail?
>>>>
>>>
>>>Actually the exceptions are wrapped but unfortunately there is no
>>>evaluation of all possible wrapping exceptions at the top level.
>>>
>>>The logging of exceptions is an issue which comes up from time
>>>to time but has never been really solved. Currently, one single
>>>exception is logged more than once because it is logged when
>>>it is thrown, it is logged when it is rethrown and it is logged
>>>when it is catched.
>>>I made several month ago the suggestion to log exceptions only
>>>when they are catched - but not when they are thrown or rethrown.
>>>They can be logged when they are thrown/rethrown when the component
>>>is in debug mode.
>>>This would make the logs much more cleaner and if then the evaluating
>>>code you suggest above is added at the top level, that would be cool.
>>>But unfortunately there was no agreement about this...
>>
>>Hmmm... the exceptions should cascade, so actually how-when it's
>>rethrown should not be an issue to understand where the problem comes
>>from, no?
>>
>
> Yes.
>
> But there was no consensus on if we should log when the exception is thrown
> or when it is catched and consumed (and not rethrown). I prever the last
> way and someone else prefered the first solution. So, it's still as it
> is and you get an exception logged more than once - blowing up the log.
It should be logged when it is consumed, because you can never tell if
you catch a new exception or an already rethrown one.
BTW, do we really need to log exceptions in the components?
I would really like to see the errors caught ONLY by Cocoon.java, and
logged there. It would reduce the problems we are having a LOT.
I have no real control on ecxeptions ATM, because of strange catching,
rethrowing... AND PLEASE, LET'S KILL THE PROCESSINGEXCEPTIONS!
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: 3 suggestions
Posted by Vadim Gritsenko <va...@verizon.net>.
Carsten Ziegeler wrote:
>Nicola Ken Barozzi wrote:
>
>
>>Carsten Ziegeler wrote:
>>
>>
>>>>-----Original Message-----
>>>>From: ola.berg@arkitema.se [mailto:ola.berg@arkitema.se]
>>>>Sent: Thursday, September 05, 2002 11:30 AM
>>>>To: cocoon-dev@xml.apache.org
>>>>Subject: 3 suggestions
>>>>
>>>>
>>>>3) src-path in the exceptions from the parsers
>>>>
>>>>As it stands, it is difficult to determine which of the sources
>>>>in a pipe that the parser compains about. Isn\'t it possible to
>>>>wrap the exceptions so that info on what part of the process that
>>>>did fail?
>>>>
>>>>
>>>>
>>>Actually the exceptions are wrapped but unfortunately there is no
>>>evaluation of all possible wrapping exceptions at the top level.
>>>
>>>The logging of exceptions is an issue which comes up from time
>>>to time but has never been really solved. Currently, one single
>>>exception is logged more than once because it is logged when
>>>it is thrown, it is logged when it is rethrown and it is logged
>>>when it is catched.
>>>I made several month ago the suggestion to log exceptions only
>>>when they are catched - but not when they are thrown or rethrown.
>>>They can be logged when they are thrown/rethrown when the component
>>>is in debug mode.
>>>This would make the logs much more cleaner and if then the evaluating
>>>code you suggest above is added at the top level, that would be cool.
>>>But unfortunately there was no agreement about this...
>>>
>>>
>>Hmmm... the exceptions should cascade, so actually how-when it's
>>rethrown should not be an issue to understand where the problem comes
>>from, no?
>>
>>
>>
>Yes.
>
>But there was no consensus on if we should log when the exception is thrown
>or when it is catched and consumed (and not rethrown). I prever the last
>way
>
+1. I thought we already agreed on this one.
Vadim
> and someone else prefered the first solution. So, it's still as it
>is and you get an exception logged more than once - blowing up the log.
>
>Carsten
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: 3 suggestions
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> Carsten Ziegeler wrote:
> >>-----Original Message-----
> >>From: ola.berg@arkitema.se [mailto:ola.berg@arkitema.se]
> >>Sent: Thursday, September 05, 2002 11:30 AM
> >>To: cocoon-dev@xml.apache.org
> >>Subject: 3 suggestions
> >>
> >>
> >>3) src-path in the exceptions from the parsers
> >>
> >>As it stands, it is difficult to determine which of the sources
> >>in a pipe that the parser compains about. Isn\'t it possible to
> >>wrap the exceptions so that info on what part of the process that
> >>did fail?
> >>
> >
> > Actually the exceptions are wrapped but unfortunately there is no
> > evaluation of all possible wrapping exceptions at the top level.
> >
> > The logging of exceptions is an issue which comes up from time
> > to time but has never been really solved. Currently, one single
> > exception is logged more than once because it is logged when
> > it is thrown, it is logged when it is rethrown and it is logged
> > when it is catched.
> > I made several month ago the suggestion to log exceptions only
> > when they are catched - but not when they are thrown or rethrown.
> > They can be logged when they are thrown/rethrown when the component
> > is in debug mode.
> > This would make the logs much more cleaner and if then the evaluating
> > code you suggest above is added at the top level, that would be cool.
> > But unfortunately there was no agreement about this...
>
> Hmmm... the exceptions should cascade, so actually how-when it's
> rethrown should not be an issue to understand where the problem comes
> from, no?
>
Yes.
But there was no consensus on if we should log when the exception is thrown
or when it is catched and consumed (and not rethrown). I prever the last
way and someone else prefered the first solution. So, it's still as it
is and you get an exception logged more than once - blowing up the log.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: 3 suggestions
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
>>-----Original Message-----
>>From: ola.berg@arkitema.se [mailto:ola.berg@arkitema.se]
>>Sent: Thursday, September 05, 2002 11:30 AM
>>To: cocoon-dev@xml.apache.org
>>Subject: 3 suggestions
>>
>>
>>3) src-path in the exceptions from the parsers
>>
>>As it stands, it is difficult to determine which of the sources
>>in a pipe that the parser compains about. Isn\'t it possible to
>>wrap the exceptions so that info on what part of the process that
>>did fail?
>>
>
> Actually the exceptions are wrapped but unfortunately there is no
> evaluation of all possible wrapping exceptions at the top level.
>
> The logging of exceptions is an issue which comes up from time
> to time but has never been really solved. Currently, one single
> exception is logged more than once because it is logged when
> it is thrown, it is logged when it is rethrown and it is logged
> when it is catched.
> I made several month ago the suggestion to log exceptions only
> when they are catched - but not when they are thrown or rethrown.
> They can be logged when they are thrown/rethrown when the component
> is in debug mode.
> This would make the logs much more cleaner and if then the evaluating
> code you suggest above is added at the top level, that would be cool.
> But unfortunately there was no agreement about this...
Hmmm... the exceptions should cascade, so actually how-when it's
rethrown should not be an issue to understand where the problem comes
from, no?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: 3 suggestions
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> -----Original Message-----
> From: ola.berg@arkitema.se [mailto:ola.berg@arkitema.se]
> Sent: Thursday, September 05, 2002 11:30 AM
> To: cocoon-dev@xml.apache.org
> Subject: 3 suggestions
>
>
> 3) src-path in the exceptions from the parsers
>
> As it stands, it is difficult to determine which of the sources
> in a pipe that the parser compains about. Isn\'t it possible to
> wrap the exceptions so that info on what part of the process that
> did fail?
>
Actually the exceptions are wrapped but unfortunately there is no
evaluation of all possible wrapping exceptions at the top level.
The logging of exceptions is an issue which comes up from time
to time but has never been really solved. Currently, one single
exception is logged more than once because it is logged when
it is thrown, it is logged when it is rethrown and it is logged
when it is catched.
I made several month ago the suggestion to log exceptions only
when they are catched - but not when they are thrown or rethrown.
They can be logged when they are thrown/rethrown when the component
is in debug mode.
This would make the logs much more cleaner and if then the evaluating
code you suggest above is added at the top level, that would be cool.
But unfortunately there was no agreement about this...
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org