You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Eric Pugh <ep...@opensourceconnections.com> on 2004/10/25 17:35:50 UTC
[configuration] Any reason why JNDIConfiguration is readonly?
Anyone have a good reason whe JNDIConfiguration doesn't support setting
properties? I was thinking of going for just a simple string storing of
properties, not binding in Datasources or anything funky like that...
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] Any reason why JNDIConfiguration is readonly?
Posted by Dakota Jack <cr...@gmail.com>.
I really like the nutshell on Java's treatment of JNDI. It is a great
job, I think.
Jack
On Wed, 27 Oct 2004 08:44:06 +0200, Eric Pugh <ep...@upstate.com> wrote:
> It should be.. However, I found it a real pain.. I think I need to really
> sit down and learn JNDI.. Write some unit tests of parsing the tree etc..
> I thought it would be a simple matter, ended up not being. Not, I think,
> because of complexity, but just my own knowhow of JNDI. Does anyone have a
> good reference to what the various things in JNDI are? "Name" and
> "Contexts" etc...? Most of the howto's I found seem too basic for me..
>
> Eric
>
> > -----Original Message-----
> > From: Oliver Heger [mailto:hegero@med.uni-marburg.de]
> > Sent: Wednesday, October 27, 2004 7:49 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: [configuration] Any reason why JNDIConfiguration is
> > readonly?
> >
> >
> > Hmm, navigating through a tree based on a configuration key, creating
> > missing nodes if necessary and finally storing the value...
> >
> > Similar code is contained in HierarchicalConfiguration and I suppose in
> > XMLConfiguration, too, to update the internally used DOM tree. I wonder
> > if this could be generalized.
> >
> > Oliver
> >
> > Eric Pugh wrote:
> > > Well.. I started on the bind/rebind stuff. and am having a really hard
> > > time of it...
> > >
> > > I can bind a property like this "newprop" just fine.. However,
> > a property
> > > like "my.newprop" fails.. I think I need to crawl the tree and find the
> > > correct context and then set that... argh..
> > >
> > > I don't just want to save in a temporary storage because I want
> > to be able
> > > to persist via JNDI configuration changes.
> > >
> > > Eric
> > >
> > >
> > >>-----Original Message-----
> > >>From: Emmanuel Bourg [mailto:smanux@lfjr.net]
> > >>Sent: Monday, October 25, 2004 5:54 PM
> > >>To: Jakarta Commons Developers List
> > >>Subject: Re: [configuration] Any reason why JNDIConfiguration is
> > >>readonly?
> > >>
> > >>
> > >>Eric Pugh wrote:
> > >>
> > >>>Anyone have a good reason whe JNDIConfiguration doesn't support setting
> > >>>properties? I was thinking of going for just a simple string
> > storing of
> > >>>properties, not binding in Datasources or anything funky like that...
> > >>>
> > >>>Eric
> > >>
> > >>How to you plan to implement this ? By playing with the
> > >>bind/rebind/unbind functions of the Context interface, or by storing the
> > >>new properties into a Map ?
> > >>
> > >>Emmanuel Bourg
> > >>
> > >>
> > >>---------------------------------------------------------------------
> > >>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
>
> ---------------------------------------------------------------------
> 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
Re: [configuration] Any reason why JNDIConfiguration is readonly?
Posted by Oliver Heger <he...@med.uni-marburg.de>.
I had a short glance at your code (not much time ATM). This seems to be
similar to my own ideas. Comments inline.
Emmanuel Bourg wrote:
[snip]
>
> - a ConfigurationNode interface is introduced, it's an abstract node
> with basic navigation methods like getElements(), createNode(),
> getName(). Its implementations will wrap a real node, that's a JNDI
> Context or a DOM Element for example.
If this ConfigurationNode interface was more powerful, it would support
generalized update methods (like setProperty(), addProperty()), too. I
attach my version from my hierarchical design, which has some more
methods. The methods dealing with attributes are a bit XML specific, but
I think it can't be wrong to use XML as a model for a generic design. So
the features of this format can be fully supported and other
configuration sources that have no attributes can provide dummy
implementations.
>
> - JNDIConfiguration implements a TreeConfiguration interface. This
> interface exposes the getRootNode() method returning the root
> ConfigurationNode. We may put in this interface some methods defining
> the variations of behaviour between the hierarchical configurations
> (supportsXXX():boolean). For example with an XMLConfiguration, several
> child nodes can have the same name, this is not true for
> JNDIConfiguration or WindowsConfiguration, that means the search
> algorithm is slightly different.
I think a generic search algorithm should be implemented to deal with
multiple occurences of child nodes. I don't like the idea of having
if-clauses based on supportsXXX() flags. If a configuration source is
restricted in this area, the specific implementation of the addChild()
method could ensure that no douplicated entries are created.
The code in HierarchicalConfiguration could serve as an example for both
the search and the add/update algorithm. With a generic node interface
that also provides a method for creating new child nodes this code can
be made generic.
One more point: Should we have a TreeConfiguration interface or add the
few additional methods to Configuration? I think the major part of
configuration sources will be hierarchical and the other ones can be
seen as hierarchical structures with only one layer. If all
Configuration classes provided a hierarchical view, there would be no
need to make distinctions later when implementing features that make use
of that (e.g. enhanced XML processing).
>
> - JNDIConfiguration has a private implementation of ConfigurationNode,
> that's JNDIConfigurationNode.
>
> - the search methods of JNDIConfiguration have been moved to
> TreeConfigurationUtils and now use the ConfigurationNode instead of the
> JNDI context.
>
> - JNDIConfiguration delegates to TreeConfigurationUtils its
> implementations for getKeys and isEmpty.
I think it makes sense to have such a class like TreeConfigurationUtils.
An alternative would be to create a base class
AbstractTreeConfiguration, but the approach with the utility class is
probably more flexible.
>
> I'm attaching the resulting classes, the test cases still pass. I
> started looking at XMLConfiguration but it's a bit more complex.
>
> Emmanuel Bourg
Oliver
Re: [configuration] Any reason why JNDIConfiguration is readonly?
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Oliver Heger wrote:
> Hmm, navigating through a tree based on a configuration key, creating
> missing nodes if necessary and finally storing the value...
>
> Similar code is contained in HierarchicalConfiguration and I suppose in
> XMLConfiguration, too, to update the internally used DOM tree. I wonder
> if this could be generalized.
I've been pondering the same thing for quite some time too. I started
working on a WindowsConfiguration wrapping the windows registry and I'm
reimplementing the same logic found in the other hierarchical
configurations. And we will have the same issue if we write a
LDAPConfiguration.
I tried a quick refactoring of JNDIConfiguration to test this idea, this
is a rough design, let me know what do you think of it :
- a ConfigurationNode interface is introduced, it's an abstract node
with basic navigation methods like getElements(), createNode(),
getName(). Its implementations will wrap a real node, that's a JNDI
Context or a DOM Element for example.
- JNDIConfiguration implements a TreeConfiguration interface. This
interface exposes the getRootNode() method returning the root
ConfigurationNode. We may put in this interface some methods defining
the variations of behaviour between the hierarchical configurations
(supportsXXX():boolean). For example with an XMLConfiguration, several
child nodes can have the same name, this is not true for
JNDIConfiguration or WindowsConfiguration, that means the search
algorithm is slightly different.
- JNDIConfiguration has a private implementation of ConfigurationNode,
that's JNDIConfigurationNode.
- the search methods of JNDIConfiguration have been moved to
TreeConfigurationUtils and now use the ConfigurationNode instead of the
JNDI context.
- JNDIConfiguration delegates to TreeConfigurationUtils its
implementations for getKeys and isEmpty.
I'm attaching the resulting classes, the test cases still pass. I
started looking at XMLConfiguration but it's a bit more complex.
Emmanuel Bourg
RE: [configuration] Any reason why JNDIConfiguration is readonly?
Posted by Eric Pugh <ep...@upstate.com>.
It should be.. However, I found it a real pain.. I think I need to really
sit down and learn JNDI.. Write some unit tests of parsing the tree etc..
I thought it would be a simple matter, ended up not being. Not, I think,
because of complexity, but just my own knowhow of JNDI. Does anyone have a
good reference to what the various things in JNDI are? "Name" and
"Contexts" etc...? Most of the howto's I found seem too basic for me..
Eric
> -----Original Message-----
> From: Oliver Heger [mailto:hegero@med.uni-marburg.de]
> Sent: Wednesday, October 27, 2004 7:49 AM
> To: Jakarta Commons Developers List
> Subject: Re: [configuration] Any reason why JNDIConfiguration is
> readonly?
>
>
> Hmm, navigating through a tree based on a configuration key, creating
> missing nodes if necessary and finally storing the value...
>
> Similar code is contained in HierarchicalConfiguration and I suppose in
> XMLConfiguration, too, to update the internally used DOM tree. I wonder
> if this could be generalized.
>
> Oliver
>
> Eric Pugh wrote:
> > Well.. I started on the bind/rebind stuff. and am having a really hard
> > time of it...
> >
> > I can bind a property like this "newprop" just fine.. However,
> a property
> > like "my.newprop" fails.. I think I need to crawl the tree and find the
> > correct context and then set that... argh..
> >
> > I don't just want to save in a temporary storage because I want
> to be able
> > to persist via JNDI configuration changes.
> >
> > Eric
> >
> >
> >>-----Original Message-----
> >>From: Emmanuel Bourg [mailto:smanux@lfjr.net]
> >>Sent: Monday, October 25, 2004 5:54 PM
> >>To: Jakarta Commons Developers List
> >>Subject: Re: [configuration] Any reason why JNDIConfiguration is
> >>readonly?
> >>
> >>
> >>Eric Pugh wrote:
> >>
> >>>Anyone have a good reason whe JNDIConfiguration doesn't support setting
> >>>properties? I was thinking of going for just a simple string
> storing of
> >>>properties, not binding in Datasources or anything funky like that...
> >>>
> >>>Eric
> >>
> >>How to you plan to implement this ? By playing with the
> >>bind/rebind/unbind functions of the Context interface, or by storing the
> >>new properties into a Map ?
> >>
> >>Emmanuel Bourg
> >>
> >>
> >>---------------------------------------------------------------------
> >>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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] Any reason why JNDIConfiguration is readonly?
Posted by Oliver Heger <he...@med.uni-marburg.de>.
Hmm, navigating through a tree based on a configuration key, creating
missing nodes if necessary and finally storing the value...
Similar code is contained in HierarchicalConfiguration and I suppose in
XMLConfiguration, too, to update the internally used DOM tree. I wonder
if this could be generalized.
Oliver
Eric Pugh wrote:
> Well.. I started on the bind/rebind stuff. and am having a really hard
> time of it...
>
> I can bind a property like this "newprop" just fine.. However, a property
> like "my.newprop" fails.. I think I need to crawl the tree and find the
> correct context and then set that... argh..
>
> I don't just want to save in a temporary storage because I want to be able
> to persist via JNDI configuration changes.
>
> Eric
>
>
>>-----Original Message-----
>>From: Emmanuel Bourg [mailto:smanux@lfjr.net]
>>Sent: Monday, October 25, 2004 5:54 PM
>>To: Jakarta Commons Developers List
>>Subject: Re: [configuration] Any reason why JNDIConfiguration is
>>readonly?
>>
>>
>>Eric Pugh wrote:
>>
>>>Anyone have a good reason whe JNDIConfiguration doesn't support setting
>>>properties? I was thinking of going for just a simple string storing of
>>>properties, not binding in Datasources or anything funky like that...
>>>
>>>Eric
>>
>>How to you plan to implement this ? By playing with the
>>bind/rebind/unbind functions of the Context interface, or by storing the
>>new properties into a Map ?
>>
>>Emmanuel Bourg
>>
>>
>>---------------------------------------------------------------------
>>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
Re: [configuration] Any reason why JNDIConfiguration is readonly?
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Eric Pugh wrote:
> Well.. I started on the bind/rebind stuff. and am having a really hard
> time of it...
>
> I can bind a property like this "newprop" just fine.. However, a property
> like "my.newprop" fails.. I think I need to crawl the tree and find the
> correct context and then set that... argh..
That's most likely the solution, and using Context.createSubcontext() if
necessary.
> I don't just want to save in a temporary storage because I want to be able
> to persist via JNDI configuration changes.
I agree, a full JNDI implementation would be better.
Good luck :)
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [configuration] Any reason why JNDIConfiguration is readonly?
Posted by Eric Pugh <ep...@upstate.com>.
Well.. I started on the bind/rebind stuff. and am having a really hard
time of it...
I can bind a property like this "newprop" just fine.. However, a property
like "my.newprop" fails.. I think I need to crawl the tree and find the
correct context and then set that... argh..
I don't just want to save in a temporary storage because I want to be able
to persist via JNDI configuration changes.
Eric
> -----Original Message-----
> From: Emmanuel Bourg [mailto:smanux@lfjr.net]
> Sent: Monday, October 25, 2004 5:54 PM
> To: Jakarta Commons Developers List
> Subject: Re: [configuration] Any reason why JNDIConfiguration is
> readonly?
>
>
> Eric Pugh wrote:
> > Anyone have a good reason whe JNDIConfiguration doesn't support setting
> > properties? I was thinking of going for just a simple string storing of
> > properties, not binding in Datasources or anything funky like that...
> >
> > Eric
>
> How to you plan to implement this ? By playing with the
> bind/rebind/unbind functions of the Context interface, or by storing the
> new properties into a Map ?
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> 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
Re: [configuration] Any reason why JNDIConfiguration is readonly?
Posted by Emmanuel Bourg <sm...@lfjr.net>.
Eric Pugh wrote:
> Anyone have a good reason whe JNDIConfiguration doesn't support setting
> properties? I was thinking of going for just a simple string storing of
> properties, not binding in Datasources or anything funky like that...
>
> Eric
How to you plan to implement this ? By playing with the
bind/rebind/unbind functions of the Context interface, or by storing the
new properties into a Map ?
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org