commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <Joerg.Schai...@Elsag-Solutions.com>
Subject RE: [configuration] Roadmap
Date Thu, 04 Mar 2004 18:36:19 GMT
Emmanuel Bourg wrote on Thursday, March 04, 2004 6:33 PM:

> Jörg Schaible wrote:
> 
>> Why drop? I haven't done much with Dom4J either, but Dom4J has a much
>> cleaner document model. Remember it's only J2sdk 1.4.x that has XML
>> support out-of-the-box, but older JDK's or J2ME (at least I think so)
>> do not have it. So Dom4J is possibly more lightweight (in this case
>> even an additional a PullParser support would make sense).
> 
> On the other hand most 1.3 environnements have the xml apis
> included in
> the jdk 1.4 as external jars. It's difficult to live without
> them ;) But
> I agree it doesn't hurt to have a dom4j implementation.
> 
> 
>>> The only issue is that it provides a copy of the Properties, I'm
>>> preparing a patch that returns a wrapper instead.
>> 
>> But what is with subsets ? I haven't look into the model too deep,
>> but will the property in the subset still know, that it is originally
>> based on a system property ? If we cannot support this, we can also
>> stay with the copy ...
> 
> Currently a subset is already a copy of the configuration
> with shortened
> keys, so once it is created it is disconnected from the parent
> configuration. I didn't notice this but you raise an
> interesting issue,
> that would be nice to keep the subset connected to the configuration,
> any change in the parent or in the subset being available in
> the other
> configuration.

At least if you come to the DB, this is necessary ...
... and leads to another interesting idea: What about a decorator for an UnmodifiableConfiguration
?
Just like it is done in java.util.Collections. Modification will throw (you will not have
the authorization to write in every DB or LDAP or ... anyway).

Regards,
Jörg

---------------------------------------------------------------------
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