avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject RE: [PATCH] Bug 6025 - The System property "app.home" contains a non-String object
Date Wed, 25 Sep 2002 10:21:13 GMT
Hi Steve, pete,

> This code, wherever it lives, results in a File Object being placed into
> the system properties, this is a problem for me because it breaks
> OpenAdaptor. OpenAdaptor creates a SuperProperties object using the
> system properties as defaults and it expects these to be Strings, which
> is quite reasonable given the contract that Properties are supposed to
> fulfill.
> 
> It is illegal for Properties to contain non-String objects, not only
> because of the contract, but also because it will cause the Properties
> store/save methods to break.  Phoenix should be using the
> setProperty(String) method instead of the put method of the underlying
> Hashmap.

>From the 1.4 apidocs for java.util.Properties:
"The Properties class represents a persistent set of properties. The
Properties can be saved to a stream or loaded from a stream. Each key
and its corresponding value in the property list is a string.

A property list can contain another property list as its "defaults";
this second property list is searched if the property key is not found
in the original property list.

Because Properties inherits from Hashtable, the put and putAll methods
can be applied to a Properties object. Their use is strongly discouraged
as they allow the caller to insert entries whose keys or values are not
Strings. The setProperty method should be used instead. If the store or
save method is called on a "compromised" Properties object that contains
a non-String key or value, the call will fail. "

Basically Sun screwed up bigtime here, and as a result you are having
problems in something called OpenAdaptor (please excuse me for not being
familiar with it).

While assuming Strings in Properties is "quite reasonable", it will
inevitably lead to problems as there are quite a few existing
applications which 'misuse' Properties by using the underlying hashmap
(which wasn't always "strongly discouraged", see
http://java.sun.com/products/jdk/1.1/docs/api/java.util.Properties.html)

This is not a bug in Phoenix at all, it is a problem with the JDK that
all apps have to live with.

On a different subject...While it would be possible to change the value
of "app.home" to a String pointing to a file, there's backwards
compatibility issues preventing this. It also fails to make sense to us,
as the variable being modified and passed on is an avalon Context
instance, which has a different contract alltogether from Properties.

Therefore, I suggest you modify OpenAdaptor to do "toStrings" on
non-string objects in Properties instances. This will shield your
applications from other apps that misuse the Properties class. Note
however, that the Context instance hosted applications receive from
phoenix is not the same as a Properties class instance.

best regards,

Leo Simons



--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message