commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <ep...@upstate.com>
Subject RE: [configuration] comma delimited properties
Date Wed, 25 Feb 2004 11:07:10 GMT
Is that going to be generic enough...  I guess one of my concerns is that as
we have more providers, like DatabaseConfiguration, that the changes we make
stay generic...

I guess, in this case, that the DatabaseConfiguration returns a string, and
then that gets converted to a list/array by AbstractConfiguration.  So, by
applying your setSplitString() method, that would solve the problem.
However, I guess we need to document that the ConfigurationFactory doesn't
support setting this method.  So, is the consensus that setSplitString() is
the way to go?  Your patch didn't seem to handle the getting, only the
setting, correct?

Part of why we want everything to inherit from AbstractConfiguration is to
help enforce similar behavior across all providers.
Eric

> -----Original Message-----
> From: Emmanuel Bourg [mailto:ebourg@micropole-univers.com]
> Sent: Wednesday, February 25, 2004 11:27 AM
> To: Jakarta Commons Developers List
> Subject: Re: [configuration] comma delimited properties
>
>
> I agree, i noticed this issue last month and suggested a patch :
>
> http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg
> 33704.html
>
> Basically it adds a setSplitString(boolean) method in the
> AbstractConfiguration class that enable or disable property splitting.
>
> Emmanuel Bourg
>
>
> Stephane Bailliez wrote:
>
> > Following a private email with Eric.
> >
> > There is an underlying problem in configuration regarding
> the handling of
> > comma delimited properties.
> > As of now, a comma delimited string is considered a list of
> values, so
> > something like:
> >
> >
> java.naming.provider.url=ldap://server:390/ou=something,o=else,c=here
> >
> > will return a list made of {
> 'ldap://server:390/ou=something' , 'o=else',
> > 'c=here' } when doing a getProperty() and a getString()
> will return the
> > first element on the list.
> >
> > Hardly a convenience to initialize an ldap/jndi connection.
> >
> > I made a couple of suggestions (some were very stupids
> actually like a
> > contract with the toString method on the object) , and Eric
> suggested a
> > decorator or a subclass.
> >
> > I'm not sure that the decorator/subclass would be
> appropriate as it would
> > probably mean yet another decoration/subclass which might
> interfere with the
> > fact that we may want this behavior in just every
> configuration class. Let's
> > face it, we may want to handle list and non list in the
> same configuration
> > subset
> >
> > I think that the best thing to do is to enforce that the
> getString() method
> > should return whatever property as its original value.
> >
> > Thoughts ?
> >
> > Stephane
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message