[configuration] New hierarchical configurations

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[configuration] New hierarchical configurations

Oliver Heger-3
I have added new hierarchical configuration implementations based on the
node handler approach.

There is now a new AbstractHierarchicalConfiguration<T> class providing
basic functionality for dealing with hierarchical structures.

Derived from that is InMemoryConfiguration, which is almost equivalent
to HierarchicalConfiguration. The new SubConfiguration class is the
counterpart to SubnodeConfiguration.

I copied the tests from the HierarchicalConfiguration, and they run
successful for the new configuration class. There are minor differences
in the handling of attributes: I decided not to allow multiple values
for an attribute as was possible for HierarchicalConfiguration as part
of the list handling functionality. IMO this was rather confusing than
helpful. Obviously these differences are not covered by the unit tests.

Next steps are further configuration implementations based on the new
classes. I will do some experiments with XMLConfiguration and a new
preferences configuration class.

We can decide how to deal with the old classes. We could completely
replace them with the new ones or deprecate them only.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [configuration] New hierarchical configurations

Jörg Schaible-2
Oliver Heger wrote:

> I have added new hierarchical configuration implementations
> based on the
> node handler approach.
>
> There is now a new AbstractHierarchicalConfiguration<T> class
> providing basic functionality for dealing with hierarchical
> structures.
>
> Derived from that is InMemoryConfiguration, which is almost equivalent
> to HierarchicalConfiguration. The new SubConfiguration class is the
> counterpart to SubnodeConfiguration.
>
> I copied the tests from the HierarchicalConfiguration, and they run
> successful for the new configuration class. There are minor
> differences in the handling of attributes: I decided not to allow
> multiple values for an attribute as was possible for
> HierarchicalConfiguration as part
> of the list handling functionality. IMO this was rather
> confusing than
> helpful. Obviously these differences are not covered by the
> unit tests.
>
> Next steps are further configuration implementations based on the new
> classes. I will do some experiments with XMLConfiguration and a new
> preferences configuration class.
>
> We can decide how to deal with the old classes. We could completely
> replace them with the new ones or deprecate them only.

For a major (incompatible) release 2.0 ... replace them. No need to burden ourselves with old code maintenance. Get rid of old stuff as soon as possible.

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] New hierarchical configurations

Oliver Heger-3
Jörg Schaible wrote:

> Oliver Heger wrote:
>
>>I have added new hierarchical configuration implementations
>>based on the
>>node handler approach.
>>
>>There is now a new AbstractHierarchicalConfiguration<T> class
>>providing basic functionality for dealing with hierarchical
>>structures.
>>
>>Derived from that is InMemoryConfiguration, which is almost equivalent
>>to HierarchicalConfiguration. The new SubConfiguration class is the
>>counterpart to SubnodeConfiguration.
>>
>>I copied the tests from the HierarchicalConfiguration, and they run
>>successful for the new configuration class. There are minor
>>differences in the handling of attributes: I decided not to allow
>>multiple values for an attribute as was possible for
>>HierarchicalConfiguration as part
>>of the list handling functionality. IMO this was rather
>>confusing than
>>helpful. Obviously these differences are not covered by the
>>unit tests.
>>
>>Next steps are further configuration implementations based on the new
>>classes. I will do some experiments with XMLConfiguration and a new
>>preferences configuration class.
>>
>>We can decide how to deal with the old classes. We could completely
>>replace them with the new ones or deprecate them only.
>
>
> For a major (incompatible) release 2.0 ... replace them. No need to burden ourselves with old code maintenance. Get rid of old stuff as soon as possible.
>
> - Jörg
>
Agreed. After refactoring of the hierarchical file-based configurations
is complete, it shows that the new configurations are indeed a full
replacement for the old ones: all unit tests are still running.

About the naming: If all our configurations are hierarchical (at least
this is the plan currently), there does not seem to be much point in
calling a concrete implementation "HierarchicalConfiguration". Therefore
I used the name "InMemoryConfiguration" for the replacement (because the
whole data is stored as ConfigurationNode objects in memory).

In the first discussions about the new configuration2 branch somebody
suggested using a different package structure, which is more focused on
modularity, i.e. there should be packages containing configuration
implementations with a specific functionality. I would like to follow
this suggestion. Any objections or further comments?

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [configuration] New hierarchical configurations

Jörg Schaible-2
Oliver Heger wrote:
[snip]
< about the naming: If all our configurations are hierarchical (at least
> this is the plan currently), there does not seem to be much point in
> calling a concrete implementation
> "HierarchicalConfiguration". Therefore
> I used the name "InMemoryConfiguration" for the replacement (because
> the whole data is stored as ConfigurationNode objects in memory).

+1

> In the first discussions about the new configuration2 branch somebody
> suggested using a different package structure, which is more
> focused on
> modularity, i.e. there should be packages containing configuration
> implementations with a specific functionality. I would like to follow
> this suggestion. Any objections or further comments?

+1

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] New hierarchical configurations

Emmanuel Bourg-3
In reply to this post by Oliver Heger-3
+1 for removing the old configurations, otherwise that would be
confusing for the users.

Regarding the package structure do you have other plans besides the
'flat' package ?

Emmanuel Bourg



> Agreed. After refactoring of the hierarchical file-based configurations
> is complete, it shows that the new configurations are indeed a full
> replacement for the old ones: all unit tests are still running.
>
> About the naming: If all our configurations are hierarchical (at least
> this is the plan currently), there does not seem to be much point in
> calling a concrete implementation "HierarchicalConfiguration". Therefore
> I used the name "InMemoryConfiguration" for the replacement (because the
> whole data is stored as ConfigurationNode objects in memory).
>
> In the first discussions about the new configuration2 branch somebody
> suggested using a different package structure, which is more focused on
> modularity, i.e. there should be packages containing configuration
> implementations with a specific functionality. I would like to follow
> this suggestion. Any objections or further comments?
>
> Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] New hierarchical configurations

Oliver Heger-3
Emmanuel Bourg schrieb:
> +1 for removing the old configurations, otherwise that would be
> confusing for the users.
>
> Regarding the package structure do you have other plans besides the
> 'flat' package ?

I would like to keep main package pretty small, so that it only contains
the basic interfaces and abstract base classes.

Sub packages would group classes with similar functionality. The plist
and web packages are good examples for that, but I am not sure how to
handle specific implementations consisting of only one or two classes
(e.g. INIConfiguration). Putting them in their own package probably does
not make too much sense.

Oliver

>
> Emmanuel Bourg
>
>
>
>> Agreed. After refactoring of the hierarchical file-based configurations
>> is complete, it shows that the new configurations are indeed a full
>> replacement for the old ones: all unit tests are still running.
>>
>> About the naming: If all our configurations are hierarchical (at least
>> this is the plan currently), there does not seem to be much point in
>> calling a concrete implementation "HierarchicalConfiguration". Therefore
>> I used the name "InMemoryConfiguration" for the replacement (because the
>> whole data is stored as ConfigurationNode objects in memory).
>>
>> In the first discussions about the new configuration2 branch somebody
>> suggested using a different package structure, which is more focused on
>> modularity, i.e. there should be packages containing configuration
>> implementations with a specific functionality. I would like to follow
>> this suggestion. Any objections or further comments?
>>
>> Oliver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] New hierarchical configurations

Emmanuel Bourg-3
Oliver Heger a écrit :
> Sub packages would group classes with similar functionality. The plist
> and web packages are good examples for that, but I am not sure how to
> handle specific implementations consisting of only one or two classes
> (e.g. INIConfiguration). Putting them in their own package probably does
> not make too much sense.

I prefer to keep the implementations in the main package, unless they
involve a lot of specific classes like the plist and web configurations.

An advantage of keeping the classes in the same package is to share
internal code with package private classes. For example JavaCC generates
several classes that don't have to be exposed to the user and can be
made package private. Theses classes could be reused for another
parsers. If we implement JSON/YAML/OGDL configuration using JavaCC that
may be nice to share these classes, but splitting the implementations in
different packages will prevent it.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] New hierarchical configurations

Emmanuel Bourg-3
In reply to this post by Oliver Heger-3
Oliver Heger a écrit :

> I would like to keep main package pretty small, so that it only contains
> the basic interfaces and abstract base classes.
>
> Sub packages would group classes with similar functionality. The plist
> and web packages are good examples for that, but I am not sure how to
> handle specific implementations consisting of only one or two classes
> (e.g. INIConfiguration). Putting them in their own package probably does
> not make too much sense.

I see a package change that might be worth considering : the 3 XMLReader
classes form a group that could be put in a sub package, o.a.c.c.xml or
o.a.c.c.sax.

What do you think ?

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] New hierarchical configurations

Oliver Heger-3
Emmanuel Bourg schrieb:

> Oliver Heger a écrit :
>
>> I would like to keep main package pretty small, so that it only
>> contains the basic interfaces and abstract base classes.
>>
>> Sub packages would group classes with similar functionality. The plist
>> and web packages are good examples for that, but I am not sure how to
>> handle specific implementations consisting of only one or two classes
>> (e.g. INIConfiguration). Putting them in their own package probably
>> does not make too much sense.
>
> I see a package change that might be worth considering : the 3 XMLReader
> classes form a group that could be put in a sub package, o.a.c.c.xml or
> o.a.c.c.sax.
>
> What do you think ?
>
> Emmanuel Bourg
>
Would XMLConfiguration also go into this package?

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] New hierarchical configurations

Emmanuel Bourg-3
Oliver Heger a écrit :

> Would XMLConfiguration also go into this package?

XMLConfiguration and XMLPropertiesConfiguration remain in the main
package. In this regard the package name o.a.c.c.sax would make more sense.

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] New hierarchical configurations

Oliver Heger-3
Emmanuel Bourg schrieb:
> Oliver Heger a écrit :
>
>> Would XMLConfiguration also go into this package?
>
> XMLConfiguration and XMLPropertiesConfiguration remain in the main
> package.
Why?

Oliver


In this regard the package name o.a.c.c.sax would make more sense.
>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] New hierarchical configurations

Emmanuel Bourg-3
Oliver Heger a écrit :

>> XMLConfiguration and XMLPropertiesConfiguration remain in the main
>> package.
> Why?

The purpose of the package is to group only the SAX readers as they form
a hierarchy providing a specific feature, just like the BeanUtils bridge
in the beanutils package. I don't know if these classes are frequently
used, actually I don't know the use cases for these readers. As a non
core feature I don't think they deserve to remain in the main package.

I don't think moving the XMLConfiguration and XMLPropertiesConfiguration
classes in an xml package is necessary, I don't have any problem with
them staying in the main package. Also, that would not make sense to
move them but not XMLPropertyListConfiguration in the plist package, and
having XMLPropertyListConfiguration outside the plist package seems
absurds too.

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] New hierarchical configurations

Oliver Heger-3
Emmanuel Bourg wrote:

> Oliver Heger a écrit :
>
>>> XMLConfiguration and XMLPropertiesConfiguration remain in the main
>>> package.
>>
>> Why?
>
>
> The purpose of the package is to group only the SAX readers as they form
> a hierarchy providing a specific feature, just like the BeanUtils bridge
> in the beanutils package. I don't know if these classes are frequently
> used, actually I don't know the use cases for these readers. As a non
> core feature I don't think they deserve to remain in the main package.
>
> I don't think moving the XMLConfiguration and XMLPropertiesConfiguration
> classes in an xml package is necessary, I don't have any problem with
> them staying in the main package. Also, that would not make sense to
> move them but not XMLPropertyListConfiguration in the plist package, and
> having XMLPropertyListConfiguration outside the plist package seems
> absurds too.
>
> Emmanuel Bourg
>
The main reason for the restructuring of the packages was to increase
modularity, which is especially important in environments like OSGi
where you have fine control over the packages to import. An "all
configurations in the main package" approach won't help here.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] New hierarchical configurations

Emmanuel Bourg-3
Oliver Heger a écrit :

> The main reason for the restructuring of the packages was to increase
> modularity, which is especially important in environments like OSGi
> where you have fine control over the packages to import. An "all
> configurations in the main package" approach won't help here.

By "increasing modularity" you mean producing several jars, one for each
implementation ?

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] New hierarchical configurations

Oliver Heger-3
Emmanuel Bourg schrieb:

> Oliver Heger a écrit :
>
>> The main reason for the restructuring of the packages was to increase
>> modularity, which is especially important in environments like OSGi
>> where you have fine control over the packages to import. An "all
>> configurations in the main package" approach won't help here.
>
> By "increasing modularity" you mean producing several jars, one for each
> implementation ?
>
> Emmanuel Bourg
>

No, at least not at the first step. I simply would like to add more
structure to our bunch of classes: lose coupling, cohesion etc.

At the moment the library is a whole "blob". Our sub packages do not
improve situation because there are cyclic dependencies everywhere. IMO
design can be improved here.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]