You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Royal <pr...@apache.org> on 2002/05/23 17:58:52 UTC
SAXConfigurationHandler bug, was Re: no log messages from phoenix?
On Wednesday 22 May 2002 09:43 pm, Peter Donald wrote:
> > > > I just sync'd with CVS today (testing the logenabled ECM :) but I not
> > > > longer get any log output!
> > >
> > > Doh! Told you I hadn't tested it ;)
> >
> > I wasn't sure if you meant just the ECM was untested or all of phoenix..
> > I don't get any log output from *any* blocks.
>
> The ECM was what I meant ... ;)
>
> My Blocks still log nice I think ...
Your ECM/LogEnabled stuff seems to work.
The culprit was SAXConfigurationHandler. For empty elements, ie <factory/>,
it was putting an empty string in the configuration instead of null and thus
when using getValue( DEFAULT ), you would not get the default, only an empty
string.
I've patched SAXConfigurationHandler to return null where the
accumulatedValue.length == 0.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SAXConfigurationHandler bug, was Re: no log messages from phoenix?
Posted by Peter Royal <pr...@apache.org>.
On Thursday 23 May 2002 02:37 pm, Gregory Steuck wrote:
> Peter> Actually you can, if you do <factory> </factory>
> Peter> and the whitespace-preservation is off, you (should) get an
> Peter> empty string since "\n".trim().equals("")
>
> This would be a hack based on knowing SAXConfigurationHandler
> internals as they are at this very moment.
Incredibly so :)
> Peter> IMHO the change should stay since it keeps prior
> Peter> behavior. (ie undeclared contract with the user). of course
> Peter> i'm biased since i spent a few hours tracking it down... :)
>
> Maybe this contract should be explicitly documented then? And a unit
> test to guarantee that this contract won't be broken later?
I added a unit test.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SAXConfigurationHandler bug, was Re: no log messages from phoenix?
Posted by Peter Royal <pr...@apache.org>.
On Thursday 23 May 2002 02:53 pm, Leo Sutic wrote:
> My reaction was against it being (to me) unintuitive - I only expected
> the default value to be used when there was *no* value provided (as
> opposed to an empty value).
A perfect example of how different people percieve things differently. I saw
the opposite. To me:
<format type="avalon"/>
vs.
<format type="avalon">...mycustomformat...</format>
I would expect the first to pick the default rather than use nothing :)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: SAXConfigurationHandler bug, was Re: no log messages from phoenix?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Gregory Steuck [mailto:greg-avalon-dev@nest.cx]
> Sent: den 23 maj 2002 20:37
> To: Avalon Developers List
> Subject: Re: SAXConfigurationHandler bug, was Re: no log
> messages from phoenix?
>
>
> ... and I thought that patch wouldn't break anything. My apologies.
>
> >>>>> "Peter" == Peter Royal <pr...@apache.org> writes:
>
> Peter> Actually you can, if you do <factory> </factory>
> Peter> and the whitespace-preservation is off, you (should) get an
> Peter> empty string since "\n".trim().equals("")
>
> This would be a hack based on knowing SAXConfigurationHandler
> internals as they are at this very moment.
>
> Peter> IMHO the change should stay since it keeps prior
> Peter> behavior. (ie undeclared contract with the user). of course
> Peter> i'm biased since i spent a few hours tracking it down... :)
>
> Maybe this contract should be explicitly documented then? And
> a unit test to guarantee that this contract won't be broken later?
If this is prior behavior, I agree. Document it and let the patch be
as is.
My reaction was against it being (to me) unintuitive - I only expected
the default value to be used when there was *no* value provided (as
opposed to an empty value).
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SAXConfigurationHandler bug, was Re: no log messages from phoenix?
Posted by Gregory Steuck <gr...@nest.cx>.
... and I thought that patch wouldn't break anything. My apologies.
>>>>> "Peter" == Peter Royal <pr...@apache.org> writes:
Peter> Actually you can, if you do <factory> </factory>
Peter> and the whitespace-preservation is off, you (should) get an
Peter> empty string since "\n".trim().equals("")
This would be a hack based on knowing SAXConfigurationHandler
internals as they are at this very moment.
Peter> IMHO the change should stay since it keeps prior
Peter> behavior. (ie undeclared contract with the user). of course
Peter> i'm biased since i spent a few hours tracking it down... :)
Maybe this contract should be explicitly documented then? And a unit
test to guarantee that this contract won't be broken later?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SAXConfigurationHandler bug, was Re: no log messages from phoenix?
Posted by Peter Royal <pr...@apache.org>.
On Thursday 23 May 2002 12:31 pm, Leo Sutic wrote:
> I'm a bit against that, as it would mean that you could not put zero
> length strings in a configuration. The default should only be applied if
> the element does not exist.
Actually you can, if you do
<factory>
</factory>
and the whitespace-preservation is off, you (should) get an empty string
since "\n".trim().equals("")
IMHO the change should stay since it keeps prior behavior. (ie undeclared
contract with the user). of course i'm biased since i spent a few hours
tracking it down... :)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: SAXConfigurationHandler bug, was Re: no log messages from phoenix?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
I'm a bit against that, as it would mean that you could not put zero
length strings in a configuration. The default should only be applied if
the element does not exist.
/LS
> -----Original Message-----
> From: Peter Royal [mailto:proyal@apache.org]
> Sent: den 23 maj 2002 17:59
> To: Avalon-Phoenix Developers List
> Cc: avalon-dev@jakarta.apache.org
> Subject: SAXConfigurationHandler bug, was Re: no log messages
> from phoenix?
>
>
> On Wednesday 22 May 2002 09:43 pm, Peter Donald wrote:
> > > > > I just sync'd with CVS today (testing the logenabled
> ECM :) but
> > > > > I not longer get any log output!
> > > >
> > > > Doh! Told you I hadn't tested it ;)
> > >
> > > I wasn't sure if you meant just the ECM was untested or all of
> > > phoenix.. I don't get any log output from *any* blocks.
> >
> > The ECM was what I meant ... ;)
> >
> > My Blocks still log nice I think ...
>
> Your ECM/LogEnabled stuff seems to work.
>
> The culprit was SAXConfigurationHandler. For empty elements,
> ie <factory/>,
> it was putting an empty string in the configuration instead
> of null and thus
> when using getValue( DEFAULT ), you would not get the
> default, only an empty
> string.
>
> I've patched SAXConfigurationHandler to return null where the
> accumulatedValue.length == 0.
> -pete
>
> --
> peter royal -> proyal@apache.org
>
> --
> To unsubscribe, e-mail:
> <mailto:avalon-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>