You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by James Taylor <jt...@4lane.com> on 2002/02/07 13:15:57 UTC
Re: cvs commit:
jakarta-turbine-torque/src/java/org/apache/torque/oid IDBroker.java
The configuration package contains an interface for accessing config
data. One implementation of Configuration is properties based, which is
similar to / based on ExtendedProperties. However using the
configuration package allows use of other (yet to be implemented)
configuration formats. An XML one is planned (the empty class is already
there). In the future others will exist, or users can implement their
own, and configure fulcrum, torque, or turbine with it.
The move is turbine level only. This is consistent with the goals of
stratum, to isolate reusable discrete components in turbine, factor them
out, refine them, and when they are ready eventually move them to
commons.
More abstraction, more flexibility.
-- jt
On Thu, 2002-02-07 at 04:17, Kelvin Tan wrote:
> I see. Hmmm...so if you don't mind me asking, what's the purpose behind this migration? Didn't see much discussion on the mailing list about this...(or I might've missed it in the noise)
>
> Is it an Apache-level move towards stratum.configuration, or is the purpose for the Turbine project to be more self-contained? And of course, the reply begs the question: if it's more or less the same, why move? :)
>
> Haven't seen the stratum.configuration package (think it was introduced yesterday or the day before only), but is it a wrapper around ExtendedProps or an implementation as well?
>
> K
> ----- Original Message -----
> From: Martin Poeschl
> To: Turbine Developers List
> Sent: Thursday, February 07, 2002 4:47 PM
> Subject: Re: cvs commit: jakarta-turbine-torque/src/java/org/apache/torque/oid IDBroker.java
>
>
> Kelvin Tan wrote:
> > I've noticed a bunch of commits moving away from Commons' ExtendedProperties, towards stratum.configuration.
> >
> > How stable is stratum.configuration wrt to ExtendedProperties? Would you consider it production-quality?
>
> the code for the configuration package is more or less the same as ExtendedProperties
>
> >
> > Regards,
> > Kelvin
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit:
jakarta-turbine-torque/src/java/org/apache/torque/oid IDBroker.java
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/8/02 8:03 AM, "James Taylor" <jt...@4lane.com> wrote:
>>> +1. The .properties-style Configuration implementation should
>>> subclass ExtendedProperties.
>>
>> No, I don't think this is right. A lot of the code was borrowed from the
>> ExtendedProperties and the core can be used in the BaseConfiguration but the
>> I/O should be removed from the ExtendedProperties and the resources package
>> should be removed. I would also like to fix some problems that are in the
>> ExtendedProperties.
>
> It seems to me that it would be nice to push some functionality up from
> ExtendedProperties. It would be nice if there were a 'MultiValueMap'
> class that handled all of the get / set stuff which
> PropertyConfiguration and ExtendedProperties could both use. Multiple
> value maps are a pretty useful reusable collection, I've ended up
> ripping those parts out of ExtendedProperties more than once when I
> needed such a collection.
All the multi-value code can be pushed into the BaseConfiguration and then
that can be further refactored and a utility can be placed in the commons
util package. That's a good idea. This is what stratum is for: to help us
decouple the turbine code and make it reusable by going back to the commons.
I realize the ExtendedProperties is already in the commons but it was more
of a stop gap solution (IMO) so that Velocity and Turbine could share this
class and to show that we too want to share out utility code (which we have
subsequently shown by moving our utility code to the commons) but I think
further work needs to be done. I would like to return the configuration
package back to the commons spiffed up so that more people can use it.
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit:
jakarta-turbine-torque/src/java/org/apache/torque/oid IDBroker.java
Posted by James Taylor <jt...@4lane.com>.
> > +1. The .properties-style Configuration implementation should
> > subclass ExtendedProperties.
>
> No, I don't think this is right. A lot of the code was borrowed from the
> ExtendedProperties and the core can be used in the BaseConfiguration but the
> I/O should be removed from the ExtendedProperties and the resources package
> should be removed. I would also like to fix some problems that are in the
> ExtendedProperties.
It seems to me that it would be nice to push some functionality up from
ExtendedProperties. It would be nice if there were a 'MultiValueMap'
class that handled all of the get / set stuff which
PropertyConfiguration and ExtendedProperties could both use. Multiple
value maps are a pretty useful reusable collection, I've ended up
ripping those parts out of ExtendedProperties more than once when I
needed such a collection.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit:
jakarta-turbine-torque/src/java/org/apache/torque/oid IDBroker.java
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/8/02 8:02 AM, "Jason van Zyl" <jv...@zenplex.com> wrote:
> On 2/7/02 10:17 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
>
>> James Taylor <jt...@4lane.com> writes:
>>
>>> The configuration package contains an interface for accessing config
>>> data. One implementation of Configuration is properties based, which is
>>> similar to / based on ExtendedProperties. However using the
>>> configuration package allows use of other (yet to be implemented)
>>> configuration formats. An XML one is planned (the empty class is already
>>> there). In the future others will exist, or users can implement their
>>> own, and configure fulcrum, torque, or turbine with it.
>>
>> +1. The .properties-style Configuration implementation should
>> subclass ExtendedProperties.
>
> No, I don't think this is right. A lot of the code was borrowed from the
> ExtendedProperties and the core can be used in the BaseConfiguration but the
> I/O should be removed from the ExtendedProperties and the resources package
> should be removed.
Sorry, that's the "resource package should be used". Not enough coffee in
the bloodstream yet.
> I would also like to fix some problems that are in the
> ExtendedProperties.
>
> The current user list of the ExtendedProperties is more then likely Turbine
> and Velocity. I believe the reworked configuration that uses the resources
> package will be a much better solution.
>
>> --
>> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit:
jakarta-turbine-torque/src/java/org/apache/torque/oid IDBroker.java
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/7/02 10:17 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> James Taylor <jt...@4lane.com> writes:
>
>> The configuration package contains an interface for accessing config
>> data. One implementation of Configuration is properties based, which is
>> similar to / based on ExtendedProperties. However using the
>> configuration package allows use of other (yet to be implemented)
>> configuration formats. An XML one is planned (the empty class is already
>> there). In the future others will exist, or users can implement their
>> own, and configure fulcrum, torque, or turbine with it.
>
> +1. The .properties-style Configuration implementation should
> subclass ExtendedProperties.
No, I don't think this is right. A lot of the code was borrowed from the
ExtendedProperties and the core can be used in the BaseConfiguration but the
I/O should be removed from the ExtendedProperties and the resources package
should be removed. I would also like to fix some problems that are in the
ExtendedProperties.
The current user list of the ExtendedProperties is more then likely Turbine
and Velocity. I believe the reworked configuration that uses the resources
package will be a much better solution.
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-turbine-torque/src/java/org/apache/torque/oid IDBroker.java
Posted by Martin Poeschl <mp...@marmot.at>.
Daniel Rall wrote:
> James Taylor <jt...@4lane.com> writes:
>
>
>>The configuration package contains an interface for accessing config
>>data. One implementation of Configuration is properties based, which is
>>similar to / based on ExtendedProperties. However using the
>>configuration package allows use of other (yet to be implemented)
>>configuration formats. An XML one is planned (the empty class is already
>>there). In the future others will exist, or users can implement their
>>own, and configure fulcrum, torque, or turbine with it.
>>
>
> +1. The .properties-style Configuration implementation should
> subclass ExtendedProperties.
why???
i think the configuration package should (and hopefully will) replace ExtendedProperties
martin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: stratum.configuration and ExtendedProperties [WAS Re: cvs
commit: jakarta-turbine-torque/src/java/org/apache/torque/oid
IDBroker.java]
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/7/02 10:48 PM, "Kelvin Tan" <ke...@relevanz.com> wrote:
>
>
>> James Taylor <jt...@4lane.com> writes:
>>
>>> The configuration package contains an interface for accessing config
>>> data. One implementation of Configuration is properties based, which is
>>> similar to / based on ExtendedProperties. However using the
>>> configuration package allows use of other (yet to be implemented)
>>> configuration formats. An XML one is planned (the empty class is already
>>> there). In the future others will exist, or users can implement their
>>> own, and configure fulcrum, torque, or turbine with it.
>>
>> +1. The .properties-style Configuration implementation should
>> subclass ExtendedProperties.
>>
>
> hmmm. I don't know about that. Currently PropertiesConfiguration already
> subclasses BaseConfiguration. What could be done would be to extract
> ExtendedProperties' method signatures into an interface and have
> PropertiesConfiguration implement that?
I believe the path we're moving down is the right one. The
ExtendedProperties needed some work anyway. It would also be nice to make
the configuration package compatible with the 1.4 Preferences API.
> Kelvin
>
>> --
>> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>>
>>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
stratum.configuration and ExtendedProperties [WAS Re: cvs commit: jakarta-turbine-torque/src/java/org/apache/torque/oid IDBroker.java]
Posted by Kelvin Tan <ke...@relevanz.com>.
> James Taylor <jt...@4lane.com> writes:
>
> > The configuration package contains an interface for accessing config
> > data. One implementation of Configuration is properties based, which is
> > similar to / based on ExtendedProperties. However using the
> > configuration package allows use of other (yet to be implemented)
> > configuration formats. An XML one is planned (the empty class is already
> > there). In the future others will exist, or users can implement their
> > own, and configure fulcrum, torque, or turbine with it.
>
> +1. The .properties-style Configuration implementation should
> subclass ExtendedProperties.
>
hmmm. I don't know about that. Currently PropertiesConfiguration already
subclasses BaseConfiguration. What could be done would be to extract
ExtendedProperties' method signatures into an interface and have
PropertiesConfiguration implement that?
Kelvin
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-turbine-torque/src/java/org/apache/torque/oid IDBroker.java
Posted by Daniel Rall <dl...@finemaltcoding.com>.
James Taylor <jt...@4lane.com> writes:
> The configuration package contains an interface for accessing config
> data. One implementation of Configuration is properties based, which is
> similar to / based on ExtendedProperties. However using the
> configuration package allows use of other (yet to be implemented)
> configuration formats. An XML one is planned (the empty class is already
> there). In the future others will exist, or users can implement their
> own, and configure fulcrum, torque, or turbine with it.
+1. The .properties-style Configuration implementation should
subclass ExtendedProperties.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit:jakarta-turbine-torque/src/java/org/apache/torque/oid IDBroker.java
Posted by Kelvin Tan <ke...@relevanz.com>.
Ok. Makes a good deal of sense. Just wasn't clear if it was duplication of effort, but if the eventual goal is to move it to Commons, don't see why not.
May be able to contribute the XML one, but have to take a look at the Configuration first.
Kelvin
----- Original Message -----
From: James Taylor
To: Turbine Developers List
Sent: Thursday, February 07, 2002 8:15 PM
Subject: Re: cvs commit:jakarta-turbine-torque/src/java/org/apache/torque/oid IDBroker.java
The configuration package contains an interface for accessing config
data. One implementation of Configuration is properties based, which is
similar to / based on ExtendedProperties. However using the
configuration package allows use of other (yet to be implemented)
configuration formats. An XML one is planned (the empty class is already
there). In the future others will exist, or users can implement their
own, and configure fulcrum, torque, or turbine with it.
The move is turbine level only. This is consistent with the goals of
stratum, to isolate reusable discrete components in turbine, factor them
out, refine them, and when they are ready eventually move them to
commons.
More abstraction, more flexibility.
-- jt
On Thu, 2002-02-07 at 04:17, Kelvin Tan wrote:
> I see. Hmmm...so if you don't mind me asking, what's the purpose behind this migration? Didn't see much discussion on the mailing list about this...(or I might've missed it in the noise)
>
> Is it an Apache-level move towards stratum.configuration, or is the purpose for the Turbine project to be more self-contained? And of course, the reply begs the question: if it's more or less the same, why move? :)
>
> Haven't seen the stratum.configuration package (think it was introduced yesterday or the day before only), but is it a wrapper around ExtendedProps or an implementation as well?
>
> K
> ----- Original Message -----
> From: Martin Poeschl
> To: Turbine Developers List
> Sent: Thursday, February 07, 2002 4:47 PM
> Subject: Re: cvs commit: jakarta-turbine-torque/src/java/org/apache/torque/oid IDBroker.java
>
>
> Kelvin Tan wrote:
> > I've noticed a bunch of commits moving away from Commons' ExtendedProperties, towards stratum.configuration.
> >
> > How stable is stratum.configuration wrt to ExtendedProperties? Would you consider it production-quality?
>
> the code for the configuration package is more or less the same as ExtendedProperties
>
> >
> > Regards,
> > Kelvin
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>