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 Donald <do...@apache.org> on 2001/04/17 13:39:31 UTC
Parametizable
Hi,
I know this was KBed last time but ... In the proposal is the interfaces for
interface Parametizabe
{
void parametize( Parameters parameters ) throws ParametersException;
}
I propose that this be included in CVS for components that Configura* is
overkill. Specifically I found that this pattern is widely used to launch
the Runtime/Kernel/Engine/whatever in a number of projects. Tomcat uses
system properties, Phoenix uses Parameters, OpenEJB uses properties, and a
few other servers I looked at have a similar arrangement.
I am not proposing that these be part of Blocks lifecycle just that they be
in CVS so that other components (like Embeddors) can make use of it rather
than using some custom method. Thoughts/Votes???
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Parametizable
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch a écrit :
>
> Sylvain Wallez wrote:
> >
> > Berin Loritsch a écrit :
> > >
> > > Peter Donald wrote:
> > > >
> > > > Hi,
> > > >
> > > > I know this was KBed last time but ... In the proposal is the interfaces for
> > > >
> > > > interface Parametizabe
> > > > {
> > > > void parametize( Parameters parameters ) throws ParametersException;
> > > > }
> > > >
> > > > I propose that this be included in CVS for components that Configura* is
> > > > overkill. Specifically I found that this pattern is widely used to launch
> > > > the Runtime/Kernel/Engine/whatever in a number of projects. Tomcat uses
> > > > system properties, Phoenix uses Parameters, OpenEJB uses properties, and a
> > > > few other servers I looked at have a similar arrangement.
> > > >
> > > > I am not proposing that these be part of Blocks lifecycle just that they be
> > > > in CVS so that other components (like Embeddors) can make use of it rather
> > > > than using some custom method. Thoughts/Votes???
> > >
> > > The Parameters class, to me, is very much the same as the Java Properties
> > > class. In fact, the biggest difference is that it can be automatically
> > > created from a Configuration object. The Parameters class is a carry over
> > > from Cocoon's old framework.
> > >
> > > So the question is, should we standardize on Properties and have a custom
> > > object that populates a Properties object from a Configuration file for us?
> > >
> > > Or should we keep the Parameters class, and use the Parameterizable interface?
> > >
> > > If we do the Parameterizable approach, then the interface is good.
> > > If we do the Properties approach, then we should have an interface like this:
> > >
> > > interface Propertizable {
> > > void propertize( Properties properties );
> > > }
> > >
> >
> > java.util.Properties extends HashMap and as such has all its methods
> > synchronized. Couldn't it have a bad impact on performances in cases
> > where synchronization is not needed ?
>
> Hashtable is synchronized, and I thought it was based on that.
> But yes, it could. How often do we refer to the original configuration
> object without caching the information in our class?
>
Sorry, I made a bad typo, I meant "Hashtable" of course (the good old
one that's been there since JDK 1.0)... HashMap (from the JDK 1.2
collections) is not synchronized.
I'm so used to type "HashMap" in my code that my fingers don't want to
type "table" after "Hash" ;-)
Sorry again for this...
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Parametizable
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
>
> Berin Loritsch a écrit :
> >
> > Peter Donald wrote:
> > >
> > > Hi,
> > >
> > > I know this was KBed last time but ... In the proposal is the interfaces for
> > >
> > > interface Parametizabe
> > > {
> > > void parametize( Parameters parameters ) throws ParametersException;
> > > }
> > >
> > > I propose that this be included in CVS for components that Configura* is
> > > overkill. Specifically I found that this pattern is widely used to launch
> > > the Runtime/Kernel/Engine/whatever in a number of projects. Tomcat uses
> > > system properties, Phoenix uses Parameters, OpenEJB uses properties, and a
> > > few other servers I looked at have a similar arrangement.
> > >
> > > I am not proposing that these be part of Blocks lifecycle just that they be
> > > in CVS so that other components (like Embeddors) can make use of it rather
> > > than using some custom method. Thoughts/Votes???
> >
> > The Parameters class, to me, is very much the same as the Java Properties
> > class. In fact, the biggest difference is that it can be automatically
> > created from a Configuration object. The Parameters class is a carry over
> > from Cocoon's old framework.
> >
> > So the question is, should we standardize on Properties and have a custom
> > object that populates a Properties object from a Configuration file for us?
> >
> > Or should we keep the Parameters class, and use the Parameterizable interface?
> >
> > If we do the Parameterizable approach, then the interface is good.
> > If we do the Properties approach, then we should have an interface like this:
> >
> > interface Propertizable {
> > void propertize( Properties properties );
> > }
> >
>
> java.util.Properties extends HashMap and as such has all its methods
> synchronized. Couldn't it have a bad impact on performances in cases
> where synchronization is not needed ?
Hashtable is synchronized, and I thought it was based on that.
But yes, it could. How often do we refer to the original configuration
object without caching the information in our class?
>
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Parametizable
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch a écrit :
>
> Peter Donald wrote:
> >
> > Hi,
> >
> > I know this was KBed last time but ... In the proposal is the interfaces for
> >
> > interface Parametizabe
> > {
> > void parametize( Parameters parameters ) throws ParametersException;
> > }
> >
> > I propose that this be included in CVS for components that Configura* is
> > overkill. Specifically I found that this pattern is widely used to launch
> > the Runtime/Kernel/Engine/whatever in a number of projects. Tomcat uses
> > system properties, Phoenix uses Parameters, OpenEJB uses properties, and a
> > few other servers I looked at have a similar arrangement.
> >
> > I am not proposing that these be part of Blocks lifecycle just that they be
> > in CVS so that other components (like Embeddors) can make use of it rather
> > than using some custom method. Thoughts/Votes???
>
> The Parameters class, to me, is very much the same as the Java Properties
> class. In fact, the biggest difference is that it can be automatically
> created from a Configuration object. The Parameters class is a carry over
> from Cocoon's old framework.
>
> So the question is, should we standardize on Properties and have a custom
> object that populates a Properties object from a Configuration file for us?
>
> Or should we keep the Parameters class, and use the Parameterizable interface?
>
> If we do the Parameterizable approach, then the interface is good.
> If we do the Properties approach, then we should have an interface like this:
>
> interface Propertizable {
> void propertize( Properties properties );
> }
>
java.util.Properties extends HashMap and as such has all its methods
synchronized. Couldn't it have a bad impact on performances in cases
where synchronization is not needed ?
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Parametizable
Posted by Leo Simons <ma...@leosimons.com>.
> > I am not proposing that these be part of Blocks lifecycle just
> that they be
> > in CVS so that other components (like Embeddors) can make use
> of it rather
> > than using some custom method. Thoughts/Votes???
Actually, I think they do need to be a part of the lifecycle, in the
sense that the point _where_ parametize() (there's a spelling glitch
in the proposal, btw), gets called should be well-defined (i.e.
between configure() and init()). Of course, it should be a completely
optional part of the lifecycle.
> The Parameters class, to me, is very much the same as the Java Properties
> class. In fact, the biggest difference is that it can be automatically
> created from a Configuration object.
Parameters has less weight since it isn't a hashmap. It also cannot be
used in a wrong way as easily as a properties class, for the same reason.
Lastly, defining it ourselves means we can make use of CascadingException
(which I've really grown attached to =).
Based on those three reasons, I think Parameters has merit on its own.
One thing that probably needs changing is that Parameters should be an
interface and DefaultParameters the implementation of that interface,
just like it is the case with Configuration and Context.
Also, it doesn't have methods where you do not have to provide default
values (useful if you're sure they are there because you control all
code).
Thirdly, if we go the interface with implementation route, we probably
still need to provide a ParameterFactory with a fromConfiguration method,
and remove the fromConfiguration from the interface. Seems cleaner
and lighter to me.
Finally, the convenience methods getParameterAsXXX are perhaps a bit
overkill (I'm trying to take into account that Avalon should be able to
run in my cellphone =).
> So the question is, should we standardize on Properties and have a custom
> object that populates a Properties object from a Configuration
> file for us?
-1
> Or should we keep the Parameters class, and use the
> Parameterizable interface?
+1, for reasons above, though with some modifications as outlined.
regards,
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Parametizable
Posted by Peter Donald <do...@apache.org>.
At 08:38 17/4/01 -0400, Berin Loritsch wrote:
>The Parameters class, to me, is very much the same as the Java Properties
>class.
agreed.
> In fact, the biggest difference is that it can be automatically
>created from a Configuration object. The Parameters class is a carry over
>from Cocoon's old framework.
The biggest difference for me is the getParameterAs<Blah> convenience methods.
>So the question is, should we standardize on Properties and have a custom
>object that populates a Properties object from a Configuration file for us?
>
>Or should we keep the Parameters class, and use the Parameterizable
interface?
>
>If we do the Parameterizable approach, then the interface is good.
>If we do the Properties approach, then we should have an interface like this:
>
>interface Propertizable {
> void propertize( Properties properties );
>}
I am good with either - I like Parameters because of convenience methods
but truth be told most of my parameters are strings ...
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Parametizable
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> Hi,
>
> I know this was KBed last time but ... In the proposal is the interfaces for
>
> interface Parametizabe
> {
> void parametize( Parameters parameters ) throws ParametersException;
> }
>
> I propose that this be included in CVS for components that Configura* is
> overkill. Specifically I found that this pattern is widely used to launch
> the Runtime/Kernel/Engine/whatever in a number of projects. Tomcat uses
> system properties, Phoenix uses Parameters, OpenEJB uses properties, and a
> few other servers I looked at have a similar arrangement.
>
> I am not proposing that these be part of Blocks lifecycle just that they be
> in CVS so that other components (like Embeddors) can make use of it rather
> than using some custom method. Thoughts/Votes???
The Parameters class, to me, is very much the same as the Java Properties
class. In fact, the biggest difference is that it can be automatically
created from a Configuration object. The Parameters class is a carry over
from Cocoon's old framework.
So the question is, should we standardize on Properties and have a custom
object that populates a Properties object from a Configuration file for us?
Or should we keep the Parameters class, and use the Parameterizable interface?
If we do the Parameterizable approach, then the interface is good.
If we do the Properties approach, then we should have an interface like this:
interface Propertizable {
void propertize( Properties properties );
}
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org