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.
