DO NOT REPLY [Bug 34103] - [configuration] Inconsistent behavior

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34103





--- Additional Comments From [EMAIL PROTECTED]  2005-03-22 08:37 ---
About PropertyDoesNotExistException: We once changed the semantic of our
getXXX(String key) methods to always throw an exception if the property does not
exist. This caused lots of protests by our users who demanded null return values
instead, so the solution with the throwExceptionOnMissing-Flag was introduced. I
think we can't change this again.

About the conversion methods: As I pointed out I don't see data conversion as a
main feature of a Configuration framework. However your approach would allow to
refactor a bunch of code dealing with data conversion (especially in
PropertiesUtils) into small and flexible converter classes that can be even
customized by the user. This is very nice.

The problem I see with this is that it is surely not easy to design a functional
hierarchy of converter classes. The [convert] sandbox project has tried exactly
that and has failed so far. So if such a conversion framework existed and could
be easily embedded into Configuration, I would give it a go. But I don't want to
develop one in the Configuration project.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34103] - [configuration] Inconsistent behavior

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34103





--- Additional Comments From [EMAIL PROTECTED]  2005-03-22 08:08 ---
ok, here's my suggestion of how Configuration should be modeled.

The basic methods will be:
   Object getProperty(String key) throws PropertyDoesNotExistException;

   Object getProperty(String key, Object default) throws ConversionException;

   Object getProperty(String key, Class cls) throws
PropertyDoesNotExistException, ConversionException;

   Object getProperty(String key, Converter conv) throws
PropertyDoesNotExistException, ConversionException;

   Object getProperty(String key, Object default, Converter conv) throws
ConversionException;
(the exceptions can/should be RuntimeExceptions, or other exceptions, like
NoSuchElementException)

all the rest of the getXXX() methods are syntactic sugar, one-liners that call
one of the getProperty() methods (second and third forms).

Converter has the API: convert(Objec o, Class cls) to convert o to an instance
of cls. converters can be registered as converting to some class (which is what
getProperty(key,cls) uses.

that's it, simple (the client needs to know only of the first 2 forms if he is
not interested in sophisticated conversions, and the return values are very
consistent, no need to read the documentation for each getXXX() method), yet
powerful (allowing me, for example, to convert a property to Map, Date etc. very
easily)

note that most of the implementation will be in getProperty(key, default,
converter) while the rest just call it (sometimes checking containsKey() before)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34103] - [configuration] Inconsistent behavior

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34103





--- Additional Comments From [EMAIL PROTECTED]  2005-03-22 07:54 ---
about getMultipleProperty, where will getProperties() map here? it returns a
non-scalar value, but not a List. What if I want (and I want) to implement a
getMap() function (which btw, means I can't work with the Configuration 
interface)?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34106] - [configuration] Property interpolation should be a decorator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34106





--- Additional Comments From [EMAIL PROTECTED]  2005-03-22 07:52 ---
Configuration gives me these over java's properties:
1. convenience methods getXXX()

2. simple (though not consistent)

3. composite configurations

4. the ability to implement my own configuration logic

5. other types of configurations, not properties based.

i don't think that having an iterpolation will make things harder for clients.
either they do 'new SomeConfiguration', in which case, they'll do 'new
InterpolationConfiguration(new SomeConfiguration)' - not much more code, but
much clearer, stating the functionality they require, and allowing them to work
without this feature, or, they use the factory, in which case it can have a
flag, on by default, that makes the factory return the configuration decorated
as the above.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34103] - [configuration] Inconsistent behavior

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34103





--- Additional Comments From [EMAIL PROTECTED]  2005-03-22 07:45 ---
i totaly agree with KISS, which is my point:
1. a getString() which takes the first element of a list is not KISS - a kiss is
that getString returns the property converted to a string. to put it in another
way, if my property is "a,b,c" i'll get "a" in return, but if it is "a-b-c",
i'll get "a-b-c". why? because i used '-' instead of ','? a KISS is that i'll
get 'a,b,c' or 'a-b-c' respectively - i get the property as-is, converted to
string. that way your model is very clear: 'getXXX() returns the property
converted to XXX', you're current model is: 'getXXX() returns the property
converted to XXX, unless the property is a List, in which case it returns the
first element'. moreover, in your current documentation this isn't even
described properly, for example, it is not mentioned for getBoolean(). 


2. about throwing an exception: the thing is you do throw this exception in many
cases, sometimes depending on a flag, sometimes not.

to summarize, my KISS model for properties is:
1. there are two types of properties: mandatory and optional. mandatory
properties mean that the client has to define them, there's no default. for
example, a URL of some server. for such properties, the code uses getXXX(key)
methods, which throw an exception if the property doesn't exist (which the code
can then catch, print an error and exit). optional properties are ones where the
code allows the client to override some default value. for this the code uses
getXXX(key, default), which doens't throw an exception if the property doesn't
exist. no flags. this is, i believe, very natural. if i have a default, i use
the optional form, if not, i use the mandatory form. the framework doesn't try
to guess defaults for me.

2. the model for the return value is always 'getXXX() returns the property
converted to XXX' an exception is thrown if the conversion fails. this exception
is a runtime exception, because it means some logical fault in the code.
conversion is done on the whole property value, not part of it. that way, a
client always knows what he's getting. if he wants the first value of a list
property he can get it like getList(key).get(0). very simple.

3. conversion is done in such a way so that custom converters can be added. that
way, if i want to get a property converted to MyClass, i call getProperty(key,
MyClass.class). simple. there's no alternative in the framework today, because i
have to work with what the interface in Configuration gives me, which will no
doubtly blow up as users will reqruie more getXXX methods.


1 & 2 give a very simple model to use. look also at bug # 34098, for a more
detailed in how the current implementation is far from KISS and confuses the
user by not being consistent in the values it returns (this is not purely
academic, but as a result of bugs i faced because, for example, i expected
getProperties(key) to return null if key doesn't exist, but instead got an empty
properties list, maybe convenient in some cases, but not KISS - no standard
returned value) 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] demonstration code

[robert burrell donkin]

On Sun, 2005-03-20 at 16:54 -0800, Craig McClanahan wrote:
> Sounds like it might fit into a "demo" or "proof of concept" directory
> now, and into the unit test suite later (when all the outstanding
> issues are addressed).

a separate directory sounds like the best approach.

i started playing with the idea that the demonstration code may be able
to be based on unit tests but i've come to the conclusion that it's
cleaner and clearer to use special demonstration code to accompany the
analysis. unit tests can then be targeted at any cases which need
addressing.

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34103] - [configuration] Inconsistent behavior

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34103





--- Additional Comments From [EMAIL PROTECTED]  2005-03-21 21:48 ---
(In reply to comment #3)
> Oliver, what about renaming this method into getScalar() or toScalar() and 
> move
> it to ConfigurationUtils or PropertyConverter ? It would extract the first
> element of the specified list or array. Then we would replace:
> 
> Object value = resolveContainerStore(key);
> 
> with:
> 
> Object value = PropertyConverter.toScalar(getProperty(key));
> 
> 

I may have to think a bit about this suggestion. To be honest I don't like the
fix for resolveContainerStore() (the bunch of if-else-statements) very much.

What about the following approach: I know we once removed that old
getPropertyDirect() method, but when I was thinking about interpolation, I had
the idea of introducing two new methods in AbstractConfiguration like the 
following:

protected Object getSingleProperty(String key);

protected abstract List getMultipleProperty(String key);

Then scalar getter methods like getString() would call the former and getters
for lists and arrays would use the latter. There could also be a default
implementation for getSingleProperty() which calls getMultipleProperty() and
returns either null or the first element.

One big advantage is that properties with multiple values are always treated as
lists. So we don't need a bunch of if-statements for conversions, but getter
methods for arrays could obtain their values directly from the list.

So with this approach it is in the responsibility of a concrete Configuration
implementation to store its properties in a way that multiple values for a
property can be returned as a list. But with our current implementation (and
especially the way AbstractConfiguration.addProperty() is implemented) this is
no problem, it should be already the case. It would be problematic if somebody
calls an addPropertyDirect() implementation in a subclass with a complex value,
but we could add a warning in the javadocs that this is not legal.

Well, in short what I try to say is that we should distinguish only between two
types of properties: scalars and lists. Other stuff like arrays should be
converted to a list when it is added (which is already done by addProperty).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34103] - [configuration] Inconsistent behavior

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34103





--- Additional Comments From [EMAIL PROTECTED]  2005-03-21 22:10 ---
Ittay,

I aggree with your points about the behavior of getter methods when the
requested property is missing. Then, if the "exception mode" is enabled, always
an exception should be thrown.

But I can't follow your points about handling of list and single properties. I
was always fine with the feature that getString() would return the first element
of a list. Your idea with supporting convertes from bean utils is interesting,
but I would add it to DataConfiguration rather than to the core Configuration
classes (and I am not sure if this feature is really needed).

My impression is that that a typical user of the Configuration API has at least
a certain idea about the properties defined in the configuration files. More
over in most cases the configuration files will be written in a way to match the
needs of the application. So it seems reasonable that the Configuration API
supports a set of default data types the properties can be converted to, but I
see no need to implement a fully featured data conversion framework.

So I guess if we implemented some of the points mentioned in the discussion
above, e.g. concatenation operations for lists, throwing exceptions but only in
a "strict" mode, we might confuse most of the users - I surely would be confused
;-) So, I say KISS - keep it stupid and simple!

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34106] - [configuration] Property interpolation should be a decorator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34106





--- Additional Comments From [EMAIL PROTECTED]  2005-03-21 23:55 ---
I agree with it as a decorator..   Unless it was somehow automatically
supplied..   Interpolation is one of the core "features" or configuration... 
Otherwise you might as well use a java.util.Property object!

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33548] - [collections] CaseInsensitiveMap performance optimization suggestion

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33548


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-03-22 00:49 ---
Thanks for your comments and suggestions.

The code key.toString() will be very quick if key is a String (it returns this,
and hotspot will deal with it if necessary). So, I don't believe that to be a
major peformance issue.

The lower casing of the string could be a little slow, however that is the kind
of issue I would want to leave to a profiler and solve if it actually caused a
problem. If you believe it would save you time, you can add the extra upper to
lower case cache by overriding this method in your own subclass.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 'Apache Commons'

[Rory Winston]

I have been examining the arguments for a java-only commons TLP. I am decidely 
+0 on the whole business, as I don't believe that there are any concrete 
benefits beyond some hand-wavey type of intangible "good feel" that will be 
magically bestowed on Jakarta commons if it takes that step. I am still a 
little baffled as to how people could have argued that Apache commons == 
Jakarta commons, when Jakarta commons is currently a sub-project of a 
sub-project of the Apache foundation? It just doesn't make any sense to me.

Henri Yandell <[EMAIL PROTECTED]> wrote:

> 
> Time for me to eat my words. Ritual disemboweling etc.
> 
> I was too eager to view a statement that "a subproject could brand
> itself as Apache Xxx providing there is no clash" (not an actual
> quote, just highlighting the statement) as meaning Commons could goto
> Apache Commons.
> 
> I took a question to the [EMAIL PROTECTED] list of  whether it was true
> that Jakarta Commons could move to commons.apache.org, and whether it
> would be required to accept common libraries in other languages.
> 
> Seems that there is thought that a) the dead commons.apache.org might
> still be a clash and b) that commons.apache.org should be language
> independent, so although there are no categorical rulings that we
> can't have a+b, they're not answers that we can take for granted
> either in thinking on TLP-ness.
> 
> So, many apologies for misleading things. I think some good has come
> of it in that it's pretty apparant that given the following two
> assurances:
> 
> a) Jakarta Commons can move to commons.apache.org
> b) Jakarta Commons can remain Java focused
> 
> there is a lot of support for Commons as a TLP, but without these two
> assurances there is not a lot.
> 
> For the record, I'm +1 on Stephen/Phil's point of view that a
> Java-only commons TLP is a +1, but otherwise it's a -1.
> 
> Hen
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 



_
Sign up for eircom broadband now and get a free two month trial.*
Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32573] - [collections] NPE: map.LRUMap.reuseMapping(LRUMap.java:272)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32573





--- Additional Comments From [EMAIL PROTECTED]  2005-03-22 01:54 ---
I can reproduce this by not synchronizing access to the LRUMap.

Thus there are now two possible causes of this:
- Mutable keys (map keys must not be changed)
- Not correctly synchronized (use Collections.synchronizedMap)

Please check your code to ensure that you are using the collections correctly.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [collections] Commons Collections contribution

[Stephen Colebourne]

I've only had a quick glance so far, but there looks like some interesting 
stuff. It will take me a little while to understand and act on any of it. If 
nothing happens, PLEASE re-promt the list!

Alternatively, raise a bugzilla call to point at your URL.
Also, I'm musing over how to enable [collections] to be a little more 
flexible in what it accepts at the moment.

Stephen
- Original Message - 
From: "Fred Loney" <[EMAIL PROTECTED]>
I would like to contribute a supplement to Collections developed over
the past couple of years. The supplement is available at:
http://www.spiritedsw.com/collections/index.html
If there is interest, I will change the copyright and submit these to
Jakarta.
Each class has a robust test case and is well-documented. I would
exclude the proxy package; the proxy package is a useful complement to
Collections, but does not belong in Collections proper.
The contribution is more substantial than a conventional patch, so I'm
not sure of the preferred submission mechanism.
Please let me know if you find this supplement useful or have any
questions.
--
Fred Loney
Spirited Software, Inc.
www.spiritedsw.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] demonstration code

[robert burrell donkin]

On Sun, 2005-03-20 at 22:22 -0800, Brian Stansberry wrote:
> --- robert burrell donkin
> <[EMAIL PROTECTED]> wrote:
> > inspired by ceki's examples, i've been working on an
> > extended systematic
> > analysis of the various classloader cases. there's
> > demonstration code
> > for them as well as documentation. it's not complete
> > but most of the
> > substantial cases address by ceki's document are
> > covered. (the
> > unconventional context classloader cases highlighted
> > by simon are
> > missing but they need a little more consideration.)
> > i think that
> > developers should find it interesting and maybe a
> > little educational. it
> > certainly help me think a lot more clearly about
> > these issues. 
> 
> Look forward to seeing this.  I was thinking of
> getting going on some unit tests based on the earlier
> analyses, but think I'll wait a bit to see what you've
> done.

i would recommend waiting.

it should be quite easy to add extra analysis cases in the same style to
the code base when it's done. i haven't covered much of the ground you
had started to explore (nor the ground suggested by simon concerning
unconventional classloaders). it would great if these could be added.

it may be a day or three before it's ready. i don't particularly want to
rush. it's easy to make mistakes when analysing these issues and it's
easy to then build misleading arguments upon shaky foundations. i hope
that people will bring any mistakes i make to our attention as quickly
as possible. 

i haven't heard any feedback about:
http://jakarta.apache.org/commons/logging/tech.html. i'll be relying on
the concepts and terminology outlined there in the analysis and
demonstration code. again, i'd like to encourage anyone who finds any
inaccuracies to speak up as soon as possible.

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34106] - [configuration] Property interpolation should be a decorator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34106





--- Additional Comments From [EMAIL PROTECTED]  2005-03-21 21:10 ---
I have some plans for enhancing interpolation support after the 1.1 release. I
plan to support other data types than string, too. Then, maybe, performance
*may* become an issue. So I have thought about a flag for disabling
interpolation support.

However I am -1 for moving interpolation functionality into a decorator. This
would make usage of this feature (which seems to me quite natural) harder, may
cause problems for configuration objects obtained from a configuration factory
and will break backwards compatibility.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34106] - [configuration] Property interpolation should be a decorator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34106





--- Additional Comments From [EMAIL PROTECTED]  2005-03-21 20:34 ---
i agree performance is not a major issue and i haven't tested it.

however, i feel it is not right to have it there, always doing its thing. if you
create an InterpolationConfiguration instead, then anyone that wants this
capability can easily use it by: new IterpolationConfiguration(config).

an example of where i can't use it in my code is a file for EL templates that I
have. if i use PropertiesConfiguration to read it, it will interpolate the
templates, which is not what I want.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34103] - [configuration] Inconsistent behavior

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34103





--- Additional Comments From [EMAIL PROTECTED]  2005-03-21 20:26 ---
I don't expect getString() to throw an exception right away, I expect it to be
written like this:
Object o = getProperty(key); // throws NoSuchElementException if no such 
prop.
return ConvertUtils.convert(o, String.class); // try to convert to string
  // if not possible, throw 
  // ConvertException

or, more generically:
public Object getProperty(String key, Class cls) {
return ConvertUtils.convert(getProperty(key), cls);
}

(the exceptions should be runtime)

therefore, getString() will return a concatenation, and getInt will throw an
exception, as should be the case. 

if the user wants to get the first element of the list, he can freely do it:
getList(key).get(0). 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34104] - [configuration] resolveContainerStore doesn't work with arrays

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34104


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Resolution||FIXED
 Status|NEW |RESOLVED




--- Additional Comments From [EMAIL PROTECTED]  2005-03-21 19:00 ---
Fixed in rev 158491:
http://svn.apache.org/viewcvs.cgi?rev=158491&view=rev

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [configuration]RC3

[Emmanuel Bourg]

Oliver Heger wrote:
I was a bit ill over the weekend, so didn't make any progress in 
creating the third release candidate. Not sure if I find any time in the 
next days, but I will try.

I had another glance at our bug list, but I think it looks good as it 
is. Or are there any ambitions in fixing any of them before RC3 (maybe 
33926, which is the only one that is no enhancement request)?
I don't think 33926 is a blocking issue for the 1.1 release.
Emmanuel Bourg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34103] - [configuration] Inconsistent behavior

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34103





--- Additional Comments From [EMAIL PROTECTED]  2005-03-21 19:25 ---
I'm not sure to understand your issue so I'll try to reformulate it, let me know
if I'm wrong. Given a configuration containing a list property:

List list = new ArrayList();
list.add("foo");
list.add("bar");
config.setProperty("key", list);

Calling config.getString("key") should throw an exception instead of returning
the first element, right ? This would happen when a "strict mode" similar to the
throwExceptionOnMissing flag is enabled. When the strict mode is disabled, you
expect the getString() method to return a concatenation of the values in the
list, that's "foo,bar".

But what happens if the property is a list of Integers and the strict mode is
disabled ? 

List list = new ArrayList();
list.add(new Integer(1));
list.add(new Integer(2));
config.setProperty("key", list);

The values can't be concatenated in this case, so what is the result of
getInt("key") ?


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 'Apache Commons'

[Henri Yandell]

Time for me to eat my words. Ritual disemboweling etc.

I was too eager to view a statement that "a subproject could brand
itself as Apache Xxx providing there is no clash" (not an actual
quote, just highlighting the statement) as meaning Commons could goto
Apache Commons.

I took a question to the [EMAIL PROTECTED] list of  whether it was true
that Jakarta Commons could move to commons.apache.org, and whether it
would be required to accept common libraries in other languages.

Seems that there is thought that a) the dead commons.apache.org might
still be a clash and b) that commons.apache.org should be language
independent, so although there are no categorical rulings that we
can't have a+b, they're not answers that we can take for granted
either in thinking on TLP-ness.

So, many apologies for misleading things. I think some good has come
of it in that it's pretty apparant that given the following two
assurances:

a) Jakarta Commons can move to commons.apache.org
b) Jakarta Commons can remain Java focused

there is a lot of support for Commons as a TLP, but without these two
assurances there is not a lot.

For the record, I'm +1 on Stephen/Phil's point of view that a
Java-only commons TLP is a +1, but otherwise it's a -1.

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r158491 - in jakarta/commons/proper/configuration/trunk: src/java/org/apache/commons/configuration/AbstractConfiguration.java src/test/org/apache/commons/configuration/TestBaseConfiguration.java xdocs/changes.xml

[ebourg]

Author: ebourg
Date: Mon Mar 21 09:58:56 2005
New Revision: 158491

URL: http://svn.apache.org/viewcvs?view=rev&rev=158491
Log:
Fix for bug 34104, resolveContainerStore now returns the first element of array 
properties

Modified:

jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestBaseConfiguration.java
jakarta/commons/proper/configuration/trunk/xdocs/changes.xml

Modified: 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java?view=diff&r1=158490&r2=158491
==
--- 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
 (original)
+++ 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/AbstractConfiguration.java
 Mon Mar 21 09:58:56 2005
@@ -906,11 +906,55 @@
 protected Object resolveContainerStore(String key)
 {
 Object value = getProperty(key);
-if (value != null && value instanceof List)
+if (value != null)
 {
-List list = (List) value;
-value = list.isEmpty() ? null : list.get(0);
+if (value instanceof List)
+{
+List list = (List) value;
+value = list.isEmpty() ? null : list.get(0);
+}
+else if (value instanceof Object[])
+{
+Object[] array = (Object[]) value;
+value = array.length == 0 ? null : array[0];
+}
+else if (value instanceof boolean[])
+{
+boolean[] array = (boolean[]) value;
+value = array.length == 0 ? null : new Boolean(array[0]);
+}
+else if (value instanceof byte[])
+{
+byte[] array = (byte[]) value;
+value = array.length == 0 ? null : new Byte(array[0]);
+}
+else if (value instanceof short[])
+{
+short[] array = (short[]) value;
+value = array.length == 0 ? null : new Short(array[0]);
+}
+else if (value instanceof int[])
+{
+int[] array = (int[]) value;
+value = array.length == 0 ? null : new Integer(array[0]);
+}
+else if (value instanceof long[])
+{
+long[] array = (long[]) value;
+value = array.length == 0 ? null : new Long(array[0]);
+}
+else if (value instanceof float[])
+{
+float[] array = (float[]) value;
+value = array.length == 0 ? null : new Float(array[0]);
+}
+else if (value instanceof double[])
+{
+double[] array = (double[]) value;
+value = array.length == 0 ? null : new Double(array[0]);
+}
 }
+
 return value;
 }
 

Modified: 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestBaseConfiguration.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestBaseConfiguration.java?view=diff&r1=158490&r2=158491
==
--- 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestBaseConfiguration.java
 (original)
+++ 
jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/TestBaseConfiguration.java
 Mon Mar 21 09:58:56 2005
@@ -623,4 +623,44 @@
 assertEquals("long value", 0xL, 
config.getBigInteger("number").longValue());
 }
 
+public void testResolveContainerStore()
+{
+AbstractConfiguration config = new BaseConfiguration();
+
+// array of objects
+config.addPropertyDirect("array", new String[] { "foo", "bar" });
+
+assertEquals("first element of the 'array' property", "foo", 
config.resolveContainerStore("array"));
+
+// list of objects
+List list = new ArrayList();
+list.add("foo");
+list.add("bar");
+config.addPropertyDirect("list", list);
+
+assertEquals("first element of the 'list' property", "foo", 
config.resolveContainerStore("list"));
+
+// arrays of primitives
+config.addPropertyDirect("array.boolean", new boolean[] { true, false 
});
+assertEquals("first element of the 'array.boolean' property", true, 
config.getBoolean("array.boolean"));
+
+config.addPropertyDirect("array.b

DO NOT REPLY [Bug 34103] - [configuration] Inconsistent behavior

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34103





--- Additional Comments From [EMAIL PROTECTED]  2005-03-21 17:45 ---
(In reply to comment #1)
> I think that the name resolveContainerStore() is not very fitting though, it
> comes from the ancient times where there was another organization for storing
> properties internally.

Oliver, what about renaming this method into getScalar() or toScalar() and move
it to ConfigurationUtils or PropertyConverter ? It would extract the first
element of the specified list or array. Then we would replace:

Object value = resolveContainerStore(key);

with:

Object value = PropertyConverter.toScalar(getProperty(key));



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34103] - [configuration] Inconsistent behavior

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34103





--- Additional Comments From [EMAIL PROTECTED]  2005-03-21 16:07 ---
for an external client calling getProperty, yes, it will return the List.

But lets say I have a property named 'foo' whose value is set to be some list. 
Now, I've written a buggy code and use getString("foo"). instead of getting an 
error (exception), this will silently be ignored. furthermore, what if i 
intended to have the property value *converted* to string (get something like 
'1,2,3', instead i'll get '1').

==> resolveContainerStore should use what getProperty() returns, and not 
manipulate it. 

this relates to issue 34098 which i've opened. namely, things should be 
consistent:
getProperty(String) should throw a NoSuchElementException (as it sometimes 
does) 
if the key doesn't exists. if isThrowXXX is used, then it should always return 
null. so should the other getXXX methods (not sometimes an empty object, like 
in 
getProperties). 




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34106] - [configuration] Property interpolation should be a decorator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34106


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|property interpolation  |[configuration] Property
   |should be a decorator   |interpolation should be a
   ||decorator
   Severity|normal  |enhancement




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34106] - [configuration] Property interpolation should be a decorator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34106





--- Additional Comments From [EMAIL PROTECTED]  2005-03-21 17:18 ---
Configuration doesn't use to be a performance critical part of an application.
Did you measure the overhead of enabling the interpolation ? I would be quite
interested in seeing the figures, I think no one studied this before. If this is
really critical I suggest adding a flag to disable the interpolation instead of
moving this core feature in a decorator.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34106] New: - property interpolation should be a decorator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34106

   Summary: property interpolation should be a decorator
   Product: Commons
   Version: unspecified
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Configuration
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


AbstractConfiguration contains code for interpolation which will run even if 
I'm 
not interested in interpolation. This is a performance issue.

Why not have InterpolatingConfiguration that adds this functionality to 
getString and getStringArray?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34098] - [configuration] Inconsistent handling for keys that don't exist

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34098





--- Additional Comments From [EMAIL PROTECTED]  2005-03-21 16:35 ---
my point is that as a user, i need to go to the javadoc every time i use a 
getXXX() method, to know what they are doing. some i need to wrap with 'catch', 
some i need to check for nullity, some i need to check for size(). i can't code 
in eclipse, completing the methods as I type and be sure of how they behave.

about throwing an exception. as you've mentioned in getShort() you must throw 
an 
exception. then why not throw it always? this will have the benefit of allowing 
a user to set a property to null if he wishes. if that user wishes not to get 
an 
exception, the rule is simple: use getProperty(key, null). in fact, i would 
discourage the usage of getXXX(key) methods, maybe even removing them 
altogether. the best approach is to always have the client tell you what the 
default value is, rather than guessing it.



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33591] - [dbcp] Connection leak in PoolableConnection.close() (Oracle 10g driver)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33591


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|[DBCP] Connection leak in   |[dbcp] Connection leak in
   |PoolableConnection.close()  |PoolableConnection.close()
   |(Oracle 10g driver) |(Oracle 10g driver)




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33461] - [beanutils] 1.6.1 cannot determine reader methods for anonymous class

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33461


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|[BeanUtils] 1.6.1 cannot|[beanutils] 1.6.1 cannot
   |determine reader methods for|determine reader methods for
   |anonymous class |anonymous class




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22384] - [validator] datePattern not supported by JavaScript

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=22384


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|datePattern not supported by|[validator] datePattern not
   |JavaScript  |supported by JavaScript




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34103] - [configuration] Inconsistent behavior

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34103


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|inconsistent behavior   |[configuration] Inconsistent
   ||behavior




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34104] New: - [configuration] resolveContainerStore doesn't work with arrays

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34104

   Summary: [configuration] resolveContainerStore doesn't work with
arrays
   Product: Commons
   Version: Nightly Builds
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Configuration
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


The resolveContainerStore method in AbstractConfiguration doesn't handle arrays.
If an array of values is stored in the configuration instead of a List,
resolveContainerStore returns the whole array instead of the first element.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34103] - inconsistent behavior

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34103





--- Additional Comments From [EMAIL PROTECTED]  2005-03-21 15:59 ---
The method resolveContainerStore() is only called by methods that return a
scalar value like getString(), getBoolean() etc. It is not involved in
getProperty() calls. So if getProperty() returns a list, this list is passed to
the caller withput modifications.

I think that the name resolveContainerStore() is not very fitting though, it
comes from the ancient times where there was another organization for storing
properties internally.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34103] New: - inconsistent behavior

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34103

   Summary: inconsistent behavior
   Product: Commons
   Version: unspecified
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Configuration
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


in AbstractConfiguration.resolveContainerStore (javadoc):

  * Returns an object from the store described by the key. If the value is a
  * List object, replace it with the first object in the list.

but what if getProperty returns a List because this is the type of the 
property? 
 this code will silently grab the first elemen. I don't understand why. 
Probably 
the reason is that some class extending AbstractConfiguration returns List for 
properties. In this case I think the better approach is to have that class 
return the first element instead, rather than returning the List and letting 
AbstractConfiguration (which is used by many other implementations, including 
outside of the configuration package) handle it

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34098] - [configuration] Inconsistent handling for keys that don't exist

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34098





--- Additional Comments From [EMAIL PROTECTED]  2005-03-21 14:12 ---
(In reply to comment #0)
> The getXXX(String key) methods in AbstractConfiguration are not consistent in 
> how they handle non-existing keys:
> getProperty(String key) - returns null

getProperty() provides a direct access to the real object stored in the
configuration, it's similar to the get() method of the Map interface and should
not be affected by the throwExceptionOnMissing flag. If you really need this
feature we could add a getObject(String) method throwing an exception when the
key doesn't exist.

> getString(String key) - throws an exception if isThrowExceptionOnMissing is 
> true
> getShort(String key) - throws an exception

getShort() returns a primitive value, we can't return a default value here even
if the throwExceptionOnMissing flag is not set.

> getStringArray(String key) - returns an empty array (why not null?)

Well, why null ? :) An empty array or list is more convenient, you don't have to
check if the value returned is null before using it. Changing the behaviour of
the getXXXArray/List methods when the throwExceptionOnMissing flag is set seems
to make sense.

> I suggest that all these methods (include getProperty()) will check 
> isThrowExceptionOnMissing and if true, throw an exception.

> As it is, it makes it hard to extend this class, and use Configuration in 
> general.

Do you have a specific use case in mind showing how you are affected by this 
issue ?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23217] - [messenger] Messenger.dtd's JNDI attributes rules mistakenly require className

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=23217


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|[Messenger] Messenger.dtd's |[messenger] Messenger.dtd's
   |JNDI attributes rules   |JNDI attributes rules
   |mistakenly require className|mistakenly require className




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33840] - [beanutils] PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33840


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|[BeanUtils] |[beanutils]
   |PropertyUtils.isReadable()  |PropertyUtils.isReadable()
   |and |and
   |PropertyUtils.getProperty() |PropertyUtils.getProperty()
   |not consistent  |not consistent




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33109] - [beanutils] Copy bean properties with different names

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33109


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|[BeanUtils]Copy bean|[beanutils] Copy bean
   |properties with different   |properties with different
   |names   |names




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34099] - [configuration] Use beanutils for conversions

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34099





--- Additional Comments From [EMAIL PROTECTED]  2005-03-21 15:21 ---
note that for enums, you write the converter only once for all your enums:

public class EnumConverter implements Converter {
public Object convert(Class classs, Object value) {
if (value == null) {
throw new ConversionException("No value specified");
}

if (value.getClass() == classs) {
return value;
}

String strValue = value.toString();

try {
return EnumUtils.getEnum(classs, strValue);
} catch (Exception e) {
throw new ConversionException("Could not convert " + strValue, e);
}
}
}


then, your code is getProperty("foo", MyEnum.class) and you get the enum.

also, the enum is the obvious example. generally speaking, i think that writing:
public class Foo {
private static void Bar b = 
Config.getConfiguration().getProperty("foo.bar", 
Bar.class);
}

is nicer than:
private static void Bar b = Bar.fromString(Config.getConfiguration().
getProperty("foo.bar"));

moreover, note that the latter form means the property must be a string, but 
what if the property can be kept as Bar (e.g., a blob in the DB) then, 
getProperty("foo.bar", Bar.class) is more suitable, since it will just return 
the property as-is.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34099] - [configuration] Use beanutils for conversions

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34099





--- Additional Comments From [EMAIL PROTECTED]  2005-03-21 14:45 ---
Being "non standard" with beanutils is not really an issue, it just means less
code reuse, and some people will argue less dependencies on external libraries.

Your suggestion of a getProperty(String, Class) method is interesting. We tried
to cover most basic types handled in configuration files with the
DataConfiguration class in the 1.1 release, let us know if you feel we forgot an
obvious type. 

Regarding enumerations I think it's easier to use a valueOf method:

MyEnum e = MyEnum.valueOf(config.getString(key));

rather than writing and registering a specific converter for this enumeration:

ConvertUtils.register(new Converter() {
public Object convert(Class type, Object value) {
return MyEnum.valueOf(String.valueOf(value));
}
}, MyEnum.class);

MyEnum e = (MyEnum) config.getProperty(key, MyEnum);



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE : [Betwixt 0.6.1-dev] Unit test errors

[Marc DEXET]

robert burrell donkin wrote:
> hi marc
> 
> looks like some tests are being thrown out by differences in
> the order of methods. this varies between JVM but i thought
> they'd all been fixed.
> 
> any chance of an idea about the platform you're running on
> and a list of all tests that fail?

Hi Robert.
Thanks.

I'm running unit test on Windows XP pack2
j2sdk1.4.2_06


[junit] [ERROR] TEST org.apache.commons.betwixt.derived.TestWriteClass
FAILED
[junit] [ERROR] TEST
org.apache.commons.betwixt.io.read.TestBindTimeTypeMapping FAILED
[junit] [ERROR] TEST
org.apache.commons.betwixt.recursion.TestSharedIDGeneration FAILED
[junit] [ERROR] TEST
org.apache.commons.betwixt.schema.TestSchemaGeneration FAILED
[junit] [ERROR] TEST
org.apache.commons.betwixt.strategy.TestConversionFlavour FAILED

I put test-reports :

Testsuite: org.apache.commons.betwixt.derived.TestWriteClass
Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 0,937 sec

Testcase:
testPropertySuppressionStrategy(org.apache.commons.betwixt.derived.TestWrite
Class): FAILED
Expected secrets to be supressed(Unequal node names) expected: but
was:
junit.framework.ComparisonFailure: Expected secrets to be supressed(Unequal
node names) expected: but was:
at
org.apache.commons.betwixt.xmlunit.XmlTestCase.testIsomorphic(XmlTestCase.ja
va:214)
at
org.apache.commons.betwixt.xmlunit.XmlTestCase.testIsomorphic(XmlTestCase.ja
va:312)
at
org.apache.commons.betwixt.xmlunit.XmlTestCase.xmlAssertIsomorphic(XmlTestCa
se.java:175)
at
org.apache.commons.betwixt.xmlunit.XmlTestCase.xmlAssertIsomorphicContent(Xm
lTestCase.java:128)
at
org.apache.commons.betwixt.xmlunit.XmlTestCase.xmlAssertIsomorphicContent(Xm
lTestCase.java:115)
at
org.apache.commons.betwixt.derived.TestWriteClass.testPropertySuppressionStr
ategy(TestWriteClass.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)


Testsuite: org.apache.commons.betwixt.io.read.TestBindTimeTypeMapping
Tests run: 10, Failures: 2, Errors: 0, Time elapsed: 0,86 sec

- Standard Error -
21 mars 2005 12:03:16 org.apache.commons.betwixt.expression.Context
popOptions
INFO: Cannot pop options off empty stack
21 mars 2005 12:03:16 org.apache.commons.betwixt.expression.Context
popOptions
INFO: Cannot pop options off empty stack
21 mars 2005 12:03:16 org.apache.commons.betwixt.expression.Context
popOptions
INFO: Cannot pop options off empty stack
21 mars 2005 12:03:16 org.apache.commons.betwixt.expression.Context
popOptions
INFO: Cannot pop options off empty stack
21 mars 2005 12:03:16 org.apache.commons.betwixt.expression.Context
popOptions
INFO: Cannot pop options off empty stack
21 mars 2005 12:03:16 org.apache.commons.betwixt.expression.Context
popOptions
INFO: Cannot pop options off empty stack
21 mars 2005 12:03:16 org.apache.commons.betwixt.expression.Context
popOptions
INFO: Cannot pop options off empty stack
21 mars 2005 12:03:16 org.apache.commons.betwixt.expression.Context
popOptions
INFO: Cannot pop options off empty stack
21 mars 2005 12:03:16 org.apache.commons.betwixt.expression.Context
popOptions
INFO: Cannot pop options off empty stack
21 mars 2005 12:03:16 org.apache.commons.betwixt.expression.Context
popOptions
INFO: Cannot pop options off empty stack
-  ---
Testcase:
testBindTimeTypeWrite(org.apache.commons.betwixt.io.read.TestBindTimeTypeMap
ping):  FAILED
(Unequal node names) expected: but was:
junit.framework.ComparisonFailure: (Unequal node names) expected: but
was:
at
org.apache.commons.betwixt.xmlunit.XmlTestCase.testIsomorphic(XmlTestCase.ja
va:214)
at
org.apache.commons.betwixt.xmlunit.XmlTestCase.testIsomorphic(XmlTestCase.ja
va:312)
at
org.apache.commons.betwixt.xmlunit.XmlTestCase.testIsomorphic(XmlTestCase.ja
va:312)
at
org.apache.commons.betwixt.xmlunit.XmlTestCase.xmlAssertIsomorphic(XmlTestCa
se.java:175)
at
org.apache.commons.betwixt.xmlunit.XmlTestCase.xmlAssertIsomorphicContent(Xm
lTestCase.java:128)
at
org.apache.commons.betwixt.xmlunit.XmlTestCase.xmlAssertIsomorphicContent(Xm
lTestCase.java:105)
at
org.apache.commons.betwixt.xmlunit.XmlTestCase.xmlAssertIsomorphicContent(Xm
lTestCase.java:96)
at
org.apache.commons.betwixt.io.read.TestBindTimeTypeMapping.testBindTimeTypeW
rite(TestBindTimeTypeMapping.java:155)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)


Testcase:
testIntrospectionTimeTypeWrite(org.apache.commons.betwixt.io.read.TestBindTi
meTypeMapping): FAILED
(Unequal node n

DO NOT REPLY [Bug 33436] - [validator] DateValidation doesn't allow dates

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33436


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|[Validator] DateValidation  |[validator] DateValidation
   |doesn't allow dates |doesn't allow dates




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33795] - [vfs] memory provider

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33795


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|[VFS] memory provider   |[vfs] memory provider




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33981] - [daemon] Setting the process name when using JSCV

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33981


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Setting the process name|[daemon] Setting the process
   |when using  JSCV|name when using JSCV




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33997] - [lang] optional precision round/trunc methods

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33997


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|optional precision  |[lang] optional precision
   |round/trunc methods |round/trunc methods




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33972] - [net] FTP Parsing off in Net Components for ACL

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33972


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|FTP Parsing off in Net  |[net] FTP Parsing off in Net
   |Components for ACL  |Components for ACL




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34099] - [configuration] Use beanutils for conversions

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34099


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|commons beanutils should be |[configuration] Use
   |used for conversions|beanutils for conversions
   Severity|normal  |enhancement




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34098] - [configuration] Inconsistent handling for keys that don't exist

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34098


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|inconsistent handling for   |[configuration] Inconsistent
   |keys that don't exist   |handling for keys that don't
   ||exist




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]