You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Kevin Sonney <ke...@webslingerz.com> on 2000/09/14 22:07:56 UTC
esql diff of the moment
Well, donald has done a supurb job on the newer error handling code in
esql. But not all the JDBC drivers set the message to something
inteligable.
Take, for example, oracle. When the oracle thin driver encounters a Column
index out of bound error, it generates the following inn getMessage() :
0
Wow! How very informative! Thanks Oracle!
So, in order to make life *MUCH* happier, here's a small pacth to dump the
stach trace to the error log. YMMV, and I'm sure there's a better way that
will put it into the doc.
Index: esql.xsl
===================================================================
RCS file: /home/cvspublic/xml-cocoon/src/org/apache/cocoon/processor/xsp/library/sql/esql.xsl,v
retrieving revision 1.12
diff -u -r1.12 esql.xsl
--- esql.xsl 2000/09/06 19:35:43 1.12
+++ esql.xsl 2000/09/14 19:46:42
@@ -266,6 +266,7 @@
} catch (Exception _esql_e) {
<exception>
<message><xsp:expr>_esql_e.getMessage()</xsp:expr></message>
+ <xsp:logic>_esql_e.printStackTrace();</xsp:logic>
</exception>
} finally {
if (_esql_session.close_connection) {
--
+-------------------------------------------+
| Kevin Sonney kevin@webslingerZ.com |
| Systems Programmer www.webslingerZ.com |
+-------------------------------------------+
Re: esql diff of the moment
Posted by Kevin Sonney <ke...@webslingerz.com>.
On Fri, 15 Sep 2000, Stefano Mazzocchi wrote:
> > Wow! How very informative! Thanks Oracle!
>
> ROTFL :)
>
> I needed that tonight, thanks Kevin :)
it *IS* kinda funny, in retrospect. However, upon discovery of this error
message, it was also subject to a very *LONG* string of explicatives.
Here's a reminder for all of us : not every vendor uses setMessage() to
do anything useful in it's exceptions. Always try to provide a stack
trace - even if it is just to the error log.
That saves a lot of hair pulling and gnashing of teeth! *grin*
--
+-------------------------------------------+
| Kevin Sonney kevin@webslingerZ.com |
| Systems Programmer www.webslingerZ.com |
+-------------------------------------------+
Re: esql diff of the moment
Posted by Stefano Mazzocchi <st...@apache.org>.
Kevin Sonney wrote:
>
> Well, donald has done a supurb job on the newer error handling code in
> esql. But not all the JDBC drivers set the message to something
> inteligable.
>
> Take, for example, oracle. When the oracle thin driver encounters a Column
> index out of bound error, it generates the following inn getMessage() :
>
> 0
>
> Wow! How very informative! Thanks Oracle!
ROTFL :)
I needed that tonight, thanks Kevin :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: esql diff of the moment
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
From: "Jeremy Quinn" <je...@media.demon.co.uk>
> At 17:50 +0200 16/09/00, Nicola Ken Barozzi wrote:
> >From: "Jeremy Quinn" <je...@media.demon.co.uk>
> >
> >> At 07:43 +0200 15/09/00, Nicola Ken Barozzi wrote:
> >> >Why not use the fixed DTD that is used now in Cocoon2 for notifications?
> >> >It's kinda standard ;-)
> >> >And all will have to go to C2 anyway.
> >> >Maybe I'm just plain dumb, but shouldn't all taglibs throw the same error
> >> >DTD? (IMHO)
> >>
> >> +1 on that!
> >>
> >> >If you agree I will make a small taglib that can be used by other taglibs
> >> >4 this.
> >>
> >> What I need for FP is to check whether any other tags had an error, so I
> >> can decide whether to serialise the DOM they are writing or not.
> >>
> >> I am adding errors to a Hashtable to do this, though it would be great if
> >> there was a general mechanism to share errors between all TagLibs on a
> >> page. They just add errors keyed to their own namespace.
> >>
> >> Wotcha reckon?
> >
> >Hmmm, I haden't thought of intra-taglib error handling... I thought that when
> >an error occurs, it is notified to the user via standard DTD... or to the
> >sitemap
> >(C2). I cannot imagine the use, because the need hasn't touched me yet, but
> >my fifth sense and 3/4 ;-) tells me I'm missing something important...
> >Could you please elaborate more on this, I'd be grateful.
> >Thanks :-)
First of all thank you for taking time to explain. :-)
And second, remember that I'm heart and soul in C2, so all my suggestions
and ideas are with C2.
Let's get going...
> My "vision" is that all TagLibs should be able to "play" together.
Ok. IMHO there seems to be a problem.
As I said other times, it seems wishful thinking that taglibs should
get along in some cases only because of mutual agreements between
authors, like in the case we had with session parameters.
> At the moment we can mostly pass the output of one to the input of another,
> though it can get tricky to write the logicsheets to allow this (bejesus, I
> still don't fully understand how this works :).
IMHO, or we have a _standard_ and _safe_ way of passing data from
taglib to taglim ("interface") or none at all.
As I explained to phone to Stefano, let's say you want to draw a chart
from data gotten from sql. You have SGL tags inside CHART tags.
The most linear, logical and Cocoon-like way of doing this is by
writing a Transformer for the chart!
It also gives you the possibility to change chart parameters in the sitemap if you
wish without changing the xml.
Charting is not data production, it's data transformation.
On the other hand, Transformers are more difficult and less speed some say...
Well for difficulty I wrote a Transformer that can simplify things, and are planning
to make taglibs suitable for transformation (don't hope too much for it guys ;-) ).
As for speed... well to pass data around you need an interface and the SAX
on is concise enough I think... are you sure it's slower? We should test IMO.
And remember: taglibs bloat method size, and for now there's still the 64K limit.
<next day I wrote>
Now I've thought of this again and changed my mind ;-)
I've started another thread for this:
Content view separation... are we making a mess? ;-)
</next day I wrote>
> The next issue that arises under this scenario it seems to me would be a
> shared error report mechanism, whereby if a TagLib writer so chose, they
> could hold off on performing an action if another TagLib had thrown an
> error.
Now, if a taglib throws an error, it means that the method in the Generator
stops and the Sitemap gets notified and acts accordingly.
Everything stops automagically.
> The obvious example of this working internally in FP, is that it will not
> serialise a modified DOM if there was some problem manipulating it (maybe a
> selector did not match).
IMHO this is something peculiar in fp... hmmm...
> Let's say I wanted to have a TagLib send a "change notification" email to
> editors when a page was successfully modified by FP, it would be handy if
> the sendmail Taglib could check to see if there were any errors in the FP
> namespace on a global XSP Error Table, before perfoming that action.
>
> At the moment in FP, errors get added to an fpErrorTable object (a tarted
> up Hashtable of Vectors of fpErrors). The LogicSheet determines a unique ID
> for each parent of an FP Tag (generate-id), writes it into the parent as an
> Attribute fp-id="N2876286428", and uses the ID as the key in the
> fpErrorTable to add new errors to the table. ie. each parent becomes a new
> key, each error happening inside that parent becomes an element of the
> Vector that has that key.
>
> At the end of processing, the whole lot is DOMed and sent to the output
> (fpErrorTable and fpError both implement XObject :), leaving the job of
> relating errors to data to the StyleSheet using the IDs.
Well these are warnings, not errors...
It means that processing can continue but it notifies the problems.
It should be up to the next component in the itemap or better to the
logic in the sitemap to decide given the warnings.
> OK, so this may not be the most elegant of solutions ..... it was designed
> for internal use ..... but something like this could be supplied
> automatically by SiLLy, no?
I cannot reply to this, I have never seen SiLLy :-)
Anyway, it seems that we failed to fully understand each other in
the first place because you see everything in XSP, I am more keen
on the full sitemap chain.
IMHO we should not try to do everything in XSP just because it's
easy, cool and fast.
Everything has its place, otherwise we would not have a pipeline
with transformers.
Speed and semplicity can come in second, otherwise all can become
a mess.
This is not meant for you in particular, Jeremy, just a general consideration
:-)
Are there any suggestions on the warning issue?
Now SAX warnings are sent to the user as errors, why not have the sitemap
decide how to handle them... don't have a clear idea yet though...
nicola_ken
Re: esql diff of the moment
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 17:50 +0200 16/09/00, Nicola Ken Barozzi wrote:
>From: "Jeremy Quinn" <je...@media.demon.co.uk>
>
>> At 07:43 +0200 15/09/00, Nicola Ken Barozzi wrote:
>> >Why not use the fixed DTD that is used now in Cocoon2 for notifications?
>> >It's kinda standard ;-)
>> >And all will have to go to C2 anyway.
>> >Maybe I'm just plain dumb, but shouldn't all taglibs throw the same error
>> >DTD? (IMHO)
>>
>> +1 on that!
>>
>> >If you agree I will make a small taglib that can be used by other taglibs
>> >4 this.
>>
>> What I need for FP is to check whether any other tags had an error, so I
>> can decide whether to serialise the DOM they are writing or not.
>>
>> I am adding errors to a Hashtable to do this, though it would be great if
>> there was a general mechanism to share errors between all TagLibs on a
>> page. They just add errors keyed to their own namespace.
>>
>> Wotcha reckon?
>
>Hmmm, I haden't thought of intra-taglib error handling... I thought that when
>an error occurs, it is notified to the user via standard DTD... or to the
>sitemap
>(C2). I cannot imagine the use, because the need hasn't touched me yet, but
>my fifth sense and 3/4 ;-) tells me I'm missing something important...
>Could you please elaborate more on this, I'd be grateful.
>Thanks :-)
My "vision" is that all TagLibs should be able to "play" together.
At the moment we can mostly pass the output of one to the input of another,
though it can get tricky to write the logicsheets to allow this (bejesus, I
still don't fully understand how this works :).
The next issue that arises under this scenario it seems to me would be a
shared error report mechanism, whereby if a TagLib writer so chose, they
could hold off on performing an action if another TagLib had thrown an
error.
The obvious example of this working internally in FP, is that it will not
serialise a modified DOM if there was some problem manipulating it (maybe a
selector did not match).
Let's say I wanted to have a TagLib send a "change notification" email to
editors when a page was successfully modified by FP, it would be handy if
the sendmail Taglib could check to see if there were any errors in the FP
namespace on a global XSP Error Table, before perfoming that action.
At the moment in FP, errors get added to an fpErrorTable object (a tarted
up Hashtable of Vectors of fpErrors). The LogicSheet determines a unique ID
for each parent of an FP Tag (generate-id), writes it into the parent as an
Attribute fp-id="N2876286428", and uses the ID as the key in the
fpErrorTable to add new errors to the table. ie. each parent becomes a new
key, each error happening inside that parent becomes an element of the
Vector that has that key.
At the end of processing, the whole lot is DOMed and sent to the output
(fpErrorTable and fpError both implement XObject :), leaving the job of
relating errors to data to the StyleSheet using the IDs.
OK, so this may not be the most elegant of solutions ..... it was designed
for internal use ..... but something like this could be supplied
automatically by SiLLy, no?
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>
Re: esql diff of the moment
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
From: "Jeremy Quinn" <je...@media.demon.co.uk>
> At 07:43 +0200 15/09/00, Nicola Ken Barozzi wrote:
> >Why not use the fixed DTD that is used now in Cocoon2 for notifications?
> >It's kinda standard ;-)
> >And all will have to go to C2 anyway.
> >Maybe I'm just plain dumb, but shouldn't all taglibs throw the same error
> >DTD? (IMHO)
>
> +1 on that!
>
> >If you agree I will make a small taglib that can be used by other taglibs
> >4 this.
>
> What I need for FP is to check whether any other tags had an error, so I
> can decide whether to serialise the DOM they are writing or not.
>
> I am adding errors to a Hashtable to do this, though it would be great if
> there was a general mechanism to share errors between all TagLibs on a
> page. They just add errors keyed to their own namespace.
>
> Wotcha reckon?
Hmmm, I haden't thought of intra-taglib error handling... I thought that when
an error occurs, it is notified to the user via standard DTD... or to the sitemap
(C2). I cannot imagine the use, because the need hasn't touched me yet, but
my fifth sense and 3/4 ;-) tells me I'm missing something important...
Could you please elaborate more on this, I'd be grateful.
Thanks :-)
nicola_ken
BTW, may it be because my body temperature exeeds 38,5 Celsius? :-(
I must be sick to think of these thing while... I'm sick ;-)
Re: esql diff of the moment
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 07:43 +0200 15/09/00, Nicola Ken Barozzi wrote:
>Why not use the fixed DTD that is used now in Cocoon2 for notifications?
>It's kinda standard ;-)
>And all will have to go to C2 anyway.
>Maybe I'm just plain dumb, but shouldn't all taglibs throw the same error
>DTD? (IMHO)
+1 on that!
>If you agree I will make a small taglib that can be used by other taglibs
>4 this.
What I need for FP is to check whether any other tags had an error, so I
can decide whether to serialise the DOM they are writing or not.
I am adding errors to a Hashtable to do this, though it would be great if
there was a general mechanism to share errors between all TagLibs on a
page. They just add errors keyed to their own namespace.
Wotcha reckon?
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>
Re: esql diff of the moment
Posted by Donald Ball <ba...@webslingerZ.com>.
On Fri, 15 Sep 2000, Nicola Ken Barozzi wrote:
> > nah, i went ahead and cleaned it up more nicely. i added a new set of
> > elements that are instantiated in case of an exception:
> >
> > <esql:error-results>
> > <message><esql:get-message/></message>
> > <tostring><esql:to-string/></tostring>
> > <stacktrace><esql:get-stacktrace/></stacktrace>
> > </esql:error-results>
>
> Why not use the fixed DTD that is used now in Cocoon2 for notifications?
> It's kinda standard ;-)
hmm, didn't know about it. a looong while ago i'd asked if any logicsheet
authors had given any thought to standardized error reporting. there was a
little discussion that resulted in no concrete proposal.
> And all will have to go to C2 anyway.
> Maybe I'm just plain dumb, but shouldn't all taglibs throw the same error
> DTD? (IMHO)
i'm honestly of two minds on this issue. on the one hand, standardization
is nice. on the other hand, suppose i don't always _want_ to see the
stacktrace - that isn't configurable via the C2 error DTD. also, more
importantly, suppose i want _actions_ to occur when an exception is thrown
- i can do that by adding xsp:logic elements to the esql:error-results
element. how could you do that using the C2 error DTD?
- donald
Re: esql diff of the moment
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Donald Ball" <ba...@webslingerZ.com>
To: <co...@xml.apache.org>
Sent: Thursday, September 14, 2000 10:49 PM
Subject: Re: esql diff of the moment
> On Thu, 14 Sep 2000, Kevin Sonney wrote:
>
> > Well, donald has done a supurb job on the newer error handling code in
> > esql. But not all the JDBC drivers set the message to something
> > inteligable.
>
> whatcha talking about? it's junky, just spits out a non-configurable chunk
> of XML...
>
> > Take, for example, oracle. When the oracle thin driver encounters a Column
> > index out of bound error, it generates the following inn getMessage() :
> >
> > 0
> >
> > Wow! How very informative! Thanks Oracle!
>
> :)
>
> > So, in order to make life *MUCH* happier, here's a small pacth to dump the
> > stach trace to the error log. YMMV, and I'm sure there's a better way that
> > will put it into the doc.
>
> nah, i went ahead and cleaned it up more nicely. i added a new set of
> elements that are instantiated in case of an exception:
>
> <esql:error-results>
> <message><esql:get-message/></message>
> <tostring><esql:to-string/></tostring>
> <stacktrace><esql:get-stacktrace/></stacktrace>
> </esql:error-results>
Why not use the fixed DTD that is used now in Cocoon2 for notifications?
It's kinda standard ;-)
And all will have to go to C2 anyway.
Maybe I'm just plain dumb, but shouldn't all taglibs throw the same error
DTD? (IMHO)
If you agree I will make a small taglib that can be used by other taglibs
4 this.
nicola_ken
Nicola Ken Barozzi - AISA Industries S.p.A
http://www.aisaindustries.it/
Via Leonardo da Vinci,2 Ticengo (CR) Italy
Research Activity:
Politecnico di Milano - Dipartimento di Meccanica
Piazza Leonardo da Vinci, n.32 - 20133 Milano (Italy)
Re: esql diff of the moment
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 14 Sep 2000, Kevin Sonney wrote:
> Well, donald has done a supurb job on the newer error handling code in
> esql. But not all the JDBC drivers set the message to something
> inteligable.
whatcha talking about? it's junky, just spits out a non-configurable chunk
of XML...
> Take, for example, oracle. When the oracle thin driver encounters a Column
> index out of bound error, it generates the following inn getMessage() :
>
> 0
>
> Wow! How very informative! Thanks Oracle!
:)
> So, in order to make life *MUCH* happier, here's a small pacth to dump the
> stach trace to the error log. YMMV, and I'm sure there's a better way that
> will put it into the doc.
nah, i went ahead and cleaned it up more nicely. i added a new set of
elements that are instantiated in case of an exception:
<esql:error-results>
<message><esql:get-message/></message>
<tostring><esql:to-string/></tostring>
<stacktrace><esql:get-stacktrace/></stacktrace>
</esql:error-results>
- donald