You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@visi.com> on 2009/08/11 08:58:10 UTC
o.a.o.util.Options improvements: NONE and ALL
While fixing some of the code around us being way too aggressive in
finding ClientModules (note that latest report with the user having
some 30+ in his classpath due to jboss libraries that specify Main-
Class in the MANIFEST.MF), I ended up wanting to switch the
openejb.deployments.classpath.require.descriptor property from a
boolean type to one that accepted an enum.
This posed some complications from a compatibility perspective.
Adding a new property was tempting, but that just raises the question
of how it relates to the old property.
Ended up making these improvements to our Options support that returns
a java.util.Set of Enum items. Should be very useful:
* ENUM SETS:
*
* Properties that accept a Set of enum values automatically accept
ALL and NONE in
* addition to the explicitly created enum items.
*
* Using ALL. This allows users to have an easy way to imply "all"
without having to
* hardcode an the entire list of enum items and protects against the
case where that
* list may grow in the future.
*
* Using NONE. This allows users an alternative to using an empty
string when explicitly
* specifying that none of the options should be used.
*
* In the internal code, this allows us to have these concepts in all
enum options
* without us having to add NONE or ALL enum items explicitly which
leads to strange code.
*
* Additionally TRUE is an alias for ALL and FALSE an alias for
NONE. This allows options
* that used to support only true/false values to be further defined
in the future without
* breaking compatibility.
Also added a ton more test for this that even include verifying the
log output. Didn't find any issues in the code regarding the logic,
but did fine a few issues in the logging which are now fixed.
-David
Re: o.a.o.util.Options improvements: NONE and ALL
Posted by David Blevins <da...@visi.com>.
I get the idea though, very good thinking. There are a few different
ways you could design that, certainly interesting.
-David
On Aug 11, 2009, at 12:13 AM, Jean-Louis MONTEIRO wrote:
>
> Sorry,
>
> NONE +THREE is a bad example as just THREE is needed ;-)
>
> Jean-Louis
>
>
> Jean-Louis MONTEIRO wrote:
>>
>> David,
>>
>> When the list is large it can be interesting to have things like
>> ALL -ONE -TWO or NONE +THREE
>>
>> Don't know if it makes sense here but it's a very common notation.
>>
>> Jean-Louis
>>
>>
>>
>> David Blevins wrote:
>>>
>>> While fixing some of the code around us being way too aggressive in
>>> finding ClientModules (note that latest report with the user having
>>> some 30+ in his classpath due to jboss libraries that specify Main-
>>> Class in the MANIFEST.MF), I ended up wanting to switch the
>>> openejb.deployments.classpath.require.descriptor property from a
>>> boolean type to one that accepted an enum.
>>>
>>> This posed some complications from a compatibility perspective.
>>> Adding a new property was tempting, but that just raises the
>>> question
>>> of how it relates to the old property.
>>>
>>> Ended up making these improvements to our Options support that
>>> returns
>>> a java.util.Set of Enum items. Should be very useful:
>>>
>>> * ENUM SETS:
>>> *
>>> * Properties that accept a Set of enum values automatically accept
>>> ALL and NONE in
>>> * addition to the explicitly created enum items.
>>> *
>>> * Using ALL. This allows users to have an easy way to imply "all"
>>> without having to
>>> * hardcode an the entire list of enum items and protects against
>>> the
>>> case where that
>>> * list may grow in the future.
>>> *
>>> * Using NONE. This allows users an alternative to using an empty
>>> string when explicitly
>>> * specifying that none of the options should be used.
>>> *
>>> * In the internal code, this allows us to have these concepts in
>>> all
>>> enum options
>>> * without us having to add NONE or ALL enum items explicitly which
>>> leads to strange code.
>>> *
>>> * Additionally TRUE is an alias for ALL and FALSE an alias for
>>> NONE. This allows options
>>> * that used to support only true/false values to be further defined
>>> in the future without
>>> * breaking compatibility.
>>>
>>> Also added a ton more test for this that even include verifying the
>>> log output. Didn't find any issues in the code regarding the logic,
>>> but did fine a few issues in the logging which are now fixed.
>>>
>>> -David
>>>
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/o.a.o.util.Options-improvements%3A-NONE-and-ALL-tp24912653p24912793.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>
>
Re: o.a.o.util.Options improvements: NONE and ALL
Posted by Jean-Louis MONTEIRO <je...@atosorigin.com>.
Sorry,
NONE +THREE is a bad example as just THREE is needed ;-)
Jean-Louis
Jean-Louis MONTEIRO wrote:
>
> David,
>
> When the list is large it can be interesting to have things like
> ALL -ONE -TWO or NONE +THREE
>
> Don't know if it makes sense here but it's a very common notation.
>
> Jean-Louis
>
>
>
> David Blevins wrote:
>>
>> While fixing some of the code around us being way too aggressive in
>> finding ClientModules (note that latest report with the user having
>> some 30+ in his classpath due to jboss libraries that specify Main-
>> Class in the MANIFEST.MF), I ended up wanting to switch the
>> openejb.deployments.classpath.require.descriptor property from a
>> boolean type to one that accepted an enum.
>>
>> This posed some complications from a compatibility perspective.
>> Adding a new property was tempting, but that just raises the question
>> of how it relates to the old property.
>>
>> Ended up making these improvements to our Options support that returns
>> a java.util.Set of Enum items. Should be very useful:
>>
>> * ENUM SETS:
>> *
>> * Properties that accept a Set of enum values automatically accept
>> ALL and NONE in
>> * addition to the explicitly created enum items.
>> *
>> * Using ALL. This allows users to have an easy way to imply "all"
>> without having to
>> * hardcode an the entire list of enum items and protects against the
>> case where that
>> * list may grow in the future.
>> *
>> * Using NONE. This allows users an alternative to using an empty
>> string when explicitly
>> * specifying that none of the options should be used.
>> *
>> * In the internal code, this allows us to have these concepts in all
>> enum options
>> * without us having to add NONE or ALL enum items explicitly which
>> leads to strange code.
>> *
>> * Additionally TRUE is an alias for ALL and FALSE an alias for
>> NONE. This allows options
>> * that used to support only true/false values to be further defined
>> in the future without
>> * breaking compatibility.
>>
>> Also added a ton more test for this that even include verifying the
>> log output. Didn't find any issues in the code regarding the logic,
>> but did fine a few issues in the logging which are now fixed.
>>
>> -David
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/o.a.o.util.Options-improvements%3A-NONE-and-ALL-tp24912653p24912793.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: o.a.o.util.Options improvements: NONE and ALL
Posted by Jean-Louis MONTEIRO <je...@atosorigin.com>.
David,
When the list is large it can be interesting to have things like
ALL -ONE -TWO or NONE +THREE
Don't know if it makes sense here but it's a very common notation.
Jean-Louis
David Blevins wrote:
>
> While fixing some of the code around us being way too aggressive in
> finding ClientModules (note that latest report with the user having
> some 30+ in his classpath due to jboss libraries that specify Main-
> Class in the MANIFEST.MF), I ended up wanting to switch the
> openejb.deployments.classpath.require.descriptor property from a
> boolean type to one that accepted an enum.
>
> This posed some complications from a compatibility perspective.
> Adding a new property was tempting, but that just raises the question
> of how it relates to the old property.
>
> Ended up making these improvements to our Options support that returns
> a java.util.Set of Enum items. Should be very useful:
>
> * ENUM SETS:
> *
> * Properties that accept a Set of enum values automatically accept
> ALL and NONE in
> * addition to the explicitly created enum items.
> *
> * Using ALL. This allows users to have an easy way to imply "all"
> without having to
> * hardcode an the entire list of enum items and protects against the
> case where that
> * list may grow in the future.
> *
> * Using NONE. This allows users an alternative to using an empty
> string when explicitly
> * specifying that none of the options should be used.
> *
> * In the internal code, this allows us to have these concepts in all
> enum options
> * without us having to add NONE or ALL enum items explicitly which
> leads to strange code.
> *
> * Additionally TRUE is an alias for ALL and FALSE an alias for
> NONE. This allows options
> * that used to support only true/false values to be further defined
> in the future without
> * breaking compatibility.
>
> Also added a ton more test for this that even include verifying the
> log output. Didn't find any issues in the code regarding the logic,
> but did fine a few issues in the logging which are now fixed.
>
> -David
>
>
>
--
View this message in context: http://www.nabble.com/o.a.o.util.Options-improvements%3A-NONE-and-ALL-tp24912653p24912740.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.