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...@upstate.com> on 2003/11/15 20:00:50 UTC
[Configuration] Formatting of digester tag
Oliver,
I was looking through the docs, and the /examples.html was a great way to
go! Something that kinda jumped out at me, having really looked at the
examples is the case where we want to load up a
HierarchicalDOM4JConfiguration:
<dom4j
className="org.apache.commons.configuration.HierarchicalDOM4JConfiguration"
fileName="tables.xml"/>
It looks a little weird to have this optional attribute "className". I am
thinking that we should change instead to:
<dom4j fileName="gui.xml"/> <!--normal dom4j -->
<hierarchicalDom4j fileName="gui.xml"/> <!--heriarchical dom4j -->
or
<hierarchical fileName="gui.xml"/> <!--heriarchical dom4j -->
I am thinking that this might be a little cleaner.. do you foresee ever
havign multiple classes providing the dom4j implementation? The className
makes sense if we had 3 or more, but with just two, where the attribute is
optional, it seems a little confusing.. any opinons?
I am hoping to work towards getting the "polish" done on
commons-configuration and then push for a move out of commons sandbox...
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Configuration] Formatting of digester tag
Posted by Oliver Heger <Ol...@t-online.de>.
Eric Pugh wrote:
>Um.. I would suggest just removing the code.. My fear when it comes to
>undocumented features is that the next committer won't have any idea what is
>going on, and will accidentally break something, especially if we don't have
>a unit test backing it up!
>
>
Sounds reasonable, I will remove it.
>Yeah, the question about a singleton is a good one.. There is so much
>opinon back and forth about the value of singletons.. I like them b/c they
>are easy.. I hate them because inevitably someone want's two configurations
>etc.. The singleton pattern can be implemented by many different containers
>if you start going the COP/IOC way.. Basically, I guess if someone wants to
>provide a good singleton implementation that has unit testing, then I'd be
>happy to have it.
>
>
True. I think it won't be possible to come up with a solution everybody
is happy with. My idea was to have a very easy way to access
configuration properties without having to bother when and where they
are loaded. But this raises a couple of questions, e.g. where to look
for the configuration definition file, naming conventions, etc.
>If you are deep and down working on ConfigurationXMLDocument, then would you
>like to wait for that before looking to move out of sandbox?
>
>Eric
>
>
ConfigurationXMLDocument is nearly finished. If nothing unexpected
happens, I think I will need about two more days for updating the
documentation. Then I can provide a final patch (including the other
points on my todo list).
Oli
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [Configuration] Formatting of digester tag
Posted by Eric Pugh <ep...@upstate.com>.
Um.. I would suggest just removing the code.. My fear when it comes to
undocumented features is that the next committer won't have any idea what is
going on, and will accidentally break something, especially if we don't have
a unit test backing it up!
Yeah, the question about a singleton is a good one.. There is so much
opinon back and forth about the value of singletons.. I like them b/c they
are easy.. I hate them because inevitably someone want's two configurations
etc.. The singleton pattern can be implemented by many different containers
if you start going the COP/IOC way.. Basically, I guess if someone wants to
provide a good singleton implementation that has unit testing, then I'd be
happy to have it.
If you are deep and down working on ConfigurationXMLDocument, then would you
like to wait for that before looking to move out of sandbox?
Eric
> -----Original Message-----
> From: Oliver Heger [mailto:Oliver.Heger@t-online.de]
> Sent: Tuesday, November 18, 2003 11:14 AM
> To: Jakarta Commons Developers List
> Subject: Re: [Configuration] Formatting of <dom4j > digester tag
>
>
> Okay, then I will change the element name to
> hierarchicalDom4j, remove
> the support for the className attribute (well I'm not sure if
> I should
> really remove this or leave it as undocumented feature; it's about a
> view lines in ConfigurationFactory that won't hurt) and update the
> examples and the overview page.
>
> At the moment I am also working on the ConfigurationXMLDocument class
> that allows XML-like processing on Configuration objects including
> interaction with Digester. I will add a section about this to the
> examples page, too.
>
> Concerning the road map: Is there still interest for the
> configuration
> singleton? I think this would be a handy feature. The
> ConfigurationService class you have written for Turbine would do the
> major part, wouldn't it?
>
> Oh, and I unfortunately don't visit the javapolis conference.
>
> Oli
>
> Eric Pugh wrote:
>
> >Humm... I thinking that either hierarchical or
> hierarchicalDom4j.. I
> >don't have a problem with long names, I think long and
> explicit is better
> >then short and confusing! I lean towards removing the attribute from
> >ConfigurationFactory to keep things as clean as possible.
> >
> >I think then that we should maybe lay out a road map of
> things to get done
> >prior to getting out of sandbox:
> >
> >1) Resolve the node name for hierarchical in dom4j.
> >2) Finish updating the docs.
> >3) Maybe get a jdbc configuration? I would love a
> JDBCConfiguration object,
> >I haven't quite taken the time to put one together, but I
> recall someone
> >mentioning they had one..
> >
> >And then get the 1.0 release done as part of moving out of
> the sandbox...
> >
> >Are you by chance going to be attending the javapolis conference?
> >(http://www.bejug.org/bejugPortal/appmanager/BeJUG/JP03)
> >
> >Eric
> >
> >
>
>
>
> ---------------------------------------------------------------------
> 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] Formatting of digester tag
Posted by Oliver Heger <Ol...@t-online.de>.
Okay, then I will change the element name to hierarchicalDom4j, remove
the support for the className attribute (well I'm not sure if I should
really remove this or leave it as undocumented feature; it's about a
view lines in ConfigurationFactory that won't hurt) and update the
examples and the overview page.
At the moment I am also working on the ConfigurationXMLDocument class
that allows XML-like processing on Configuration objects including
interaction with Digester. I will add a section about this to the
examples page, too.
Concerning the road map: Is there still interest for the configuration
singleton? I think this would be a handy feature. The
ConfigurationService class you have written for Turbine would do the
major part, wouldn't it?
Oh, and I unfortunately don't visit the javapolis conference.
Oli
Eric Pugh wrote:
>Humm... I thinking that either hierarchical or hierarchicalDom4j.. I
>don't have a problem with long names, I think long and explicit is better
>then short and confusing! I lean towards removing the attribute from
>ConfigurationFactory to keep things as clean as possible.
>
>I think then that we should maybe lay out a road map of things to get done
>prior to getting out of sandbox:
>
>1) Resolve the node name for hierarchical in dom4j.
>2) Finish updating the docs.
>3) Maybe get a jdbc configuration? I would love a JDBCConfiguration object,
>I haven't quite taken the time to put one together, but I recall someone
>mentioning they had one..
>
>And then get the 1.0 release done as part of moving out of the sandbox...
>
>Are you by chance going to be attending the javapolis conference?
>(http://www.bejug.org/bejugPortal/appmanager/BeJUG/JP03)
>
>Eric
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [Configuration] Formatting of digester tag
Posted by Eric Pugh <ep...@upstate.com>.
Humm... I thinking that either hierarchical or hierarchicalDom4j.. I
don't have a problem with long names, I think long and explicit is better
then short and confusing! I lean towards removing the attribute from
ConfigurationFactory to keep things as clean as possible.
I think then that we should maybe lay out a road map of things to get done
prior to getting out of sandbox:
1) Resolve the node name for hierarchical in dom4j.
2) Finish updating the docs.
3) Maybe get a jdbc configuration? I would love a JDBCConfiguration object,
I haven't quite taken the time to put one together, but I recall someone
mentioning they had one..
And then get the 1.0 release done as part of moving out of the sandbox...
Are you by chance going to be attending the javapolis conference?
(http://www.bejug.org/bejugPortal/appmanager/BeJUG/JP03)
Eric
> -----Original Message-----
> From: Oliver Heger [mailto:Oliver.Heger@t-online.de]
> Sent: Sunday, November 16, 2003 7:06 PM
> To: Jakarta Commons Developers List
> Subject: Re: [Configuration] Formatting of <dom4j > digester tag
>
>
> Eric,
>
> I think you are right with that className attribute. I have only
> restored support for it (for in the actual implementation it was not
> even evaluated) because the examples in the overview.html all had a
> className attribute. And at this time this was the easiest
> possibility
> to include HierarchicalDOM4JConfiguration as a configuration
> source for
> ConfigurationFactory.
>
> From a user's point of view it is surely cleaner to have a
> separate XML
> element. Should I change the code in ConfigurationFactory to
> completely
> get rid off this attribute (in theory it can be set for all other
> elements as well, but this doesn't make much sense)?
>
> Which element name do you prefer? hierarchical, hierarchicalDom4j,
> hieraDom4j, ...? (I have always trouble with comming up with a
> meaningful name).
>
> Hey, I really would like to see commons configuration comming
> out of the
> sandbox!
>
> Oli
>
> Eric Pugh wrote:
>
> >Oliver,
> >
> >I was looking through the docs, and the /examples.html was a
> great way to
> >go! Something that kinda jumped out at me, having really
> looked at the
> >examples is the case where we want to load up a
> >HierarchicalDOM4JConfiguration:
> >
> ><dom4j
> >className="org.apache.commons.configuration.HierarchicalDOM4J
> Configuration"
> > fileName="tables.xml"/>
> >
> >It looks a little weird to have this optional attribute
> "className". I am
> >thinking that we should change instead to:
> >
> > <dom4j fileName="gui.xml"/> <!--normal dom4j -->
> > <hierarchicalDom4j fileName="gui.xml"/> <!--heriarchical dom4j -->
> >or
> > <hierarchical fileName="gui.xml"/> <!--heriarchical dom4j -->
> >
> >I am thinking that this might be a little cleaner.. do you
> foresee ever
> >havign multiple classes providing the dom4j implementation?
> The className
> >makes sense if we had 3 or more, but with just two, where
> the attribute is
> >optional, it seems a little confusing.. any opinons?
> >
> >I am hoping to work towards getting the "polish" done on
> >commons-configuration and then push for a move out of
> commons sandbox...
> >
> >Eric
> >
> >
> >
> >---------------------------------------------------------------------
> >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] Formatting of digester tag
Posted by Oliver Heger <Ol...@t-online.de>.
Eric,
I think you are right with that className attribute. I have only
restored support for it (for in the actual implementation it was not
even evaluated) because the examples in the overview.html all had a
className attribute. And at this time this was the easiest possibility
to include HierarchicalDOM4JConfiguration as a configuration source for
ConfigurationFactory.
From a user's point of view it is surely cleaner to have a separate XML
element. Should I change the code in ConfigurationFactory to completely
get rid off this attribute (in theory it can be set for all other
elements as well, but this doesn't make much sense)?
Which element name do you prefer? hierarchical, hierarchicalDom4j,
hieraDom4j, ...? (I have always trouble with comming up with a
meaningful name).
Hey, I really would like to see commons configuration comming out of the
sandbox!
Oli
Eric Pugh wrote:
>Oliver,
>
>I was looking through the docs, and the /examples.html was a great way to
>go! Something that kinda jumped out at me, having really looked at the
>examples is the case where we want to load up a
>HierarchicalDOM4JConfiguration:
>
><dom4j
>className="org.apache.commons.configuration.HierarchicalDOM4JConfiguration"
> fileName="tables.xml"/>
>
>It looks a little weird to have this optional attribute "className". I am
>thinking that we should change instead to:
>
> <dom4j fileName="gui.xml"/> <!--normal dom4j -->
> <hierarchicalDom4j fileName="gui.xml"/> <!--heriarchical dom4j -->
>or
> <hierarchical fileName="gui.xml"/> <!--heriarchical dom4j -->
>
>I am thinking that this might be a little cleaner.. do you foresee ever
>havign multiple classes providing the dom4j implementation? The className
>makes sense if we had 3 or more, but with just two, where the attribute is
>optional, it seems a little confusing.. any opinons?
>
>I am hoping to work towards getting the "polish" done on
>commons-configuration and then push for a move out of commons sandbox...
>
>Eric
>
>
>
>---------------------------------------------------------------------
>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