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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
