You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/04/09 19:45:44 UTC
Inefficiencies in DefaultConfiguration
Please look here (AbstractConfiguration)
public String getValue( final String defaultValue )
{
try
{
return getValue();
}
catch( final ConfigurationException ce )
{
return defaultValue;
}
}
then look here
public String getValue() throws ConfigurationException
{
if( null != m_value )
{
return m_value;
}
else
{
throw new ConfigurationException( "No value is associated
with the "+
"configuration element \""
+ getName() +
"\" at " + getLocation()
);
}
}
Can somebody tell me why we have to:
1) create three strings
2) call two methods
3) create an exception object
4) throw the exception
5) and then throw everything away.
in order to resort to the default value?
I understand that getValue() doesn't return null, but this seems utterly
inefficient to me.
Considering that Cocoon calls this method "a lot" no wonder why Cocoon
startup is slow as hell.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Inefficiencies in DefaultConfiguration
Posted by Peter Donald <pe...@apache.org>.
On Thu, 11 Apr 2002 06:18, Stefano Mazzocchi wrote:
> Peter Donald wrote:
> > On Wed, 10 Apr 2002 03:45, Stefano Mazzocchi wrote:
> > > Can somebody tell me why we have to:
> > >
> > > 1) create three strings
> > > 2) call two methods
> > > 3) create an exception object
> > > 4) throw the exception
> > > 5) and then throw everything away.
> > >
> > > in order to resort to the default value?
> >
> > Its legacy inherited from previous authors ;)
> >
> :-)
:)
> > I fixed this up in CVS but similar ineficiancies are present with many of
> > the getAttribute*() methods. It would be good if a patch was supplied to
> > rectify this ;)
>
> My suggestion would be *not* to use wrap the default-lacking methods in
> the abstract classes but provide different methods for the empty methods
> (which trigger an exception if the configuration isn't found) and for
> those with have the default passed (which never trigger an exception).
agreed.
--
Cheers,
Pete
It said "Don't Panic" in big friendly letters.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Inefficiencies in DefaultConfiguration
Posted by Peter Donald <pe...@apache.org>.
On Wed, 24 Apr 2002 00:41, Vadim Gritsenko wrote:
> Hi all,
>
> Attached is a patch which reduces amount of throw/catches to the
> minimum. Functionality wasn't changed, except that ParameterException is
> not wrapped twice in getParameterAsXXX(String name) methods. Hope this
> is Ok.
Patch applied - thanks!
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[PATCH] Inefficiencies in DefaultConfiguration
Posted by Vadim Gritsenko <va...@verizon.net>.
Hi all,
Attached is a patch which reduces amount of throw/catches to the
minimum. Functionality wasn't changed, except that ParameterException is
not wrapped twice in getParameterAsXXX(String name) methods. Hope this
is Ok.
Vadim
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> Peter Donald wrote:
> >
> > On Wed, 10 Apr 2002 03:45, Stefano Mazzocchi wrote:
> > > Can somebody tell me why we have to:
> > >
> > > 1) create three strings
> > > 2) call two methods
> > > 3) create an exception object
> > > 4) throw the exception
> > > 5) and then throw everything away.
> > >
> > > in order to resort to the default value?
> >
> > Its legacy inherited from previous authors ;)
>
> :-)
>
> > I fixed this up in CVS but similar ineficiancies are present with
many
> > of the
> > getAttribute*() methods. It would be good if a patch was supplied to
> > rectify this ;)
>
> My suggestion would be *not* to use wrap the default-lacking methods
in
> the abstract classes but provide different methods for the empty
methods
> (which trigger an exception if the configuration isn't found) and for
> those with have the default passed (which never trigger an exception).
>
> But before submitting patches I wanted to discuss a little bit about
it.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
Re: Inefficiencies in DefaultConfiguration
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
>
> On Wed, 10 Apr 2002 03:45, Stefano Mazzocchi wrote:
> > Can somebody tell me why we have to:
> >
> > 1) create three strings
> > 2) call two methods
> > 3) create an exception object
> > 4) throw the exception
> > 5) and then throw everything away.
> >
> > in order to resort to the default value?
>
> Its legacy inherited from previous authors ;)
:-)
> I fixed this up in CVS but similar ineficiancies are present with many of the
> getAttribute*() methods. It would be good if a patch was supplied to rectify
> this ;)
My suggestion would be *not* to use wrap the default-lacking methods in
the abstract classes but provide different methods for the empty methods
(which trigger an exception if the configuration isn't found) and for
those with have the default passed (which never trigger an exception).
But before submitting patches I wanted to discuss a little bit about it.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Inefficiencies in DefaultConfiguration
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
>
> On Wed, 10 Apr 2002 03:45, Stefano Mazzocchi wrote:
> > Can somebody tell me why we have to:
> >
> > 1) create three strings
> > 2) call two methods
> > 3) create an exception object
> > 4) throw the exception
> > 5) and then throw everything away.
> >
> > in order to resort to the default value?
>
> Its legacy inherited from previous authors ;)
:-)
> I fixed this up in CVS but similar ineficiancies are present with many of the
> getAttribute*() methods. It would be good if a patch was supplied to rectify
> this ;)
My suggestion would be *not* to use wrap the default-lacking methods in
the abstract classes but provide different methods for the empty methods
(which trigger an exception if the configuration isn't found) and for
those with have the default passed (which never trigger an exception).
But before submitting patches I wanted to discuss a little bit about it.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Inefficiencies in DefaultConfiguration
Posted by Peter Donald <pe...@apache.org>.
On Wed, 10 Apr 2002 03:45, Stefano Mazzocchi wrote:
> Can somebody tell me why we have to:
>
> 1) create three strings
> 2) call two methods
> 3) create an exception object
> 4) throw the exception
> 5) and then throw everything away.
>
> in order to resort to the default value?
Its legacy inherited from previous authors ;)
I fixed this up in CVS but similar ineficiancies are present with many of the
getAttribute*() methods. It would be good if a patch was supplied to rectify
this ;)
--
Cheers,
Pete
---------------------------------------------------
Murphy's law - "Anything that can go wrong, will."
(Actually, this is Finagle's law, which in itself
shows that Finagle was right.)
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Inefficiencies in DefaultConfiguration
Posted by Peter Donald <pe...@apache.org>.
On Wed, 10 Apr 2002 03:45, Stefano Mazzocchi wrote:
> Can somebody tell me why we have to:
>
> 1) create three strings
> 2) call two methods
> 3) create an exception object
> 4) throw the exception
> 5) and then throw everything away.
>
> in order to resort to the default value?
Its legacy inherited from previous authors ;)
I fixed this up in CVS but similar ineficiancies are present with many of the
getAttribute*() methods. It would be good if a patch was supplied to rectify
this ;)
--
Cheers,
Pete
---------------------------------------------------
Murphy's law - "Anything that can go wrong, will."
(Actually, this is Finagle's law, which in itself
shows that Finagle was right.)
---------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Inefficiencies in DefaultConfiguration
Posted by Leo Simons <le...@apache.org>.
You have a good point. I'm happy to apply any patches that
address it.
cheers,
- Leo
> -----Oorspronkelijk bericht-----
> Van: Stefano Mazzocchi [mailto:stefano@apache.org]
> Verzonden: Tuesday, April 09, 2002 7:46 PM
> Aan: Apache Avalon
> CC: Apache Cocoon
> Onderwerp: Inefficiencies in DefaultConfiguration
>
>
> Please look here (AbstractConfiguration)
>
> public String getValue( final String defaultValue )
> {
> try
> {
> return getValue();
> }
> catch( final ConfigurationException ce )
> {
> return defaultValue;
> }
> }
>
> then look here
>
> public String getValue() throws ConfigurationException
> {
> if( null != m_value )
> {
> return m_value;
> }
> else
> {
> throw new ConfigurationException( "No value is associated
> with the "+
> "configuration element \""
> + getName() +
> "\" at " + getLocation()
> );
> }
> }
>
> Can somebody tell me why we have to:
>
> 1) create three strings
> 2) call two methods
> 3) create an exception object
> 4) throw the exception
> 5) and then throw everything away.
>
> in order to resort to the default value?
>
> I understand that getValue() doesn't return null, but this seems utterly
> inefficient to me.
>
> Considering that Cocoon calls this method "a lot" no wonder why Cocoon
> startup is slow as hell.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@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>