Ralph Goers schrieb:
On Dec 20, 2008, at 7:32 AM, Oliver Heger wrote:
Just another point: There are other flat configuration implementations
that do not extend BaseConfiguration, e.g. the web configurations or
DatabaseConfiguration. AbstractFlagConfiguration was intended to serve
as a commo
On Dec 20, 2008, at 7:32 AM, Oliver Heger wrote:
Just another point: There are other flat configuration
implementations that do not extend BaseConfiguration, e.g. the web
configurations or DatabaseConfiguration. AbstractFlagConfiguration
was intended to serve as a common base class for al
Ralph Goers schrieb:
On Dec 15, 2008, at 1:22 PM, Oliver Heger wrote:
Ralph Goers schrieb:
On Dec 13, 2008, at 12:42 PM, Oliver Heger wrote:
I don't think any dummy implementations are needed. If
BaseConfiguration extended AbstractHierarchicalConfiguration instead
of AbstractFlatConfigur
On Dec 15, 2008, at 1:22 PM, Oliver Heger wrote:
Ralph Goers schrieb:
On Dec 13, 2008, at 12:42 PM, Oliver Heger wrote:
I don't think any dummy implementations are needed. If
BaseConfiguration extended AbstractHierarchicalConfiguration
instead of AbstractFlatConfiguration it would need
Ralph Goers schrieb:
On Dec 13, 2008, at 12:42 PM, Oliver Heger wrote:
Ralph Goers schrieb:
The problem I have is with the interface. Forcing applications to use
AbstractHierarchicalConfiguration as the "base" configuration object
they code to is wrong, IMO. Either they should use the Co
On Dec 13, 2008, at 12:42 PM, Oliver Heger wrote:
Ralph Goers schrieb:
The problem I have is with the interface. Forcing applications to
use AbstractHierarchicalConfiguration as the "base" configuration
object they code to is wrong, IMO. Either they should use the
Configuration interf
Ralph Goers schrieb:
On Dec 13, 2008, at 7:28 AM, Oliver Heger wrote:
There are of course configurations like MapConfiguration that are not
hierarchical by nature. The classes in the "flat" package provide a
hierarchical view on these classes. The idea is that when a
hierarchical node struc
On Dec 13, 2008, at 7:28 AM, Oliver Heger wrote:
There are of course configurations like MapConfiguration that are
not hierarchical by nature. The classes in the "flat" package
provide a hierarchical view on these classes. The idea is that when
a hierarchical node structure is needed, it
Ralph Goers schrieb:
On Nov 13, 2008, at 1:13 PM, Oliver Heger wrote:
Ralph Goers schrieb:
The problem is that in applications using commons config they would
like to specify an interface in lots of places.
HierarchicalConfiguration would be perfect for that. It should just
extend the Confi
On Nov 13, 2008, at 1:13 PM, Oliver Heger wrote:
Ralph Goers schrieb:
The problem is that in applications using commons config they would
like to specify an interface in lots of places.
HierarchicalConfiguration would be perfect for that. It should just
extend the Configuration interface.
I have no problem with using Configuration instead of
HierarchicalConfiguration except that it doesn't contain all the necessary
methods yet.
I guess from what you are telling me is that the branch is kind of half-way
between the 1.x branch and where it is intended to go. That's fine. It just
mea
Ralph Goers schrieb:
The problem is that in applications using commons config they would like
to specify an interface in lots of places. HierarchicalConfiguration
would be perfect for that. It should just extend the Configuration
interface.
It was discussed that in configuration2 all configur
The problem is that in applications using commons config they would like
to specify an interface in lots of places. HierarchicalConfiguration
would be perfect for that. It should just extend the Configuration
interface.
I'm also a little confused over CombinedConfiguration and
ExpressionEngin
Ralph Goers schrieb:
I've noticed that HierarchicalConfiguration isn't part of the
inheritance for the various hierarchical implementations. This seems
rather odd. What base class are applications migrating to configuration2
supposed to convert all their references to? In fact, I'm wondering i
I've noticed that HierarchicalConfiguration isn't part of the
inheritance for the various hierarchical implementations. This seems
rather odd. What base class are applications migrating to configuration2
supposed to convert all their references to? In fact, I'm wondering if
HierarchicalConfigu
15 matches
Mail list logo
