Bugs item #791195, was opened at 2003-08-19 05:48
Message generated for change (Comment added) made by starksm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=791195&group_id=22866

Category: JBossServer
Group: v3.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tomasz Stanczak (tstanczak)
Assigned to: Scott M Stark (starksm)
Summary: PropertyMap disallows changes to JNDI System properties

Initial Comment:
The class org.jboss.util.property.PropertyManager in its 
static part creates an instance of 
org.jboss.util.property.PropertyMap and replaces the 
original System properties using this new instance, 
after copying its content into the PropertyMap (which 
descends from Properties).

According to the comments in the source of 
PropertyManager this is done to enable notifications 
about changes through System.setProperty().

The PropertyMap has yet another feature - it caches all 
the JNDI related properties in a separate Map to 
optimize access.

A side effect of all this is that JNDI related properties 
remain read-only for the time after the replacemens of 
the original System properties.

The reason: the getProperty method looks up the 
internal cache before asking original properties for a 
value. For all JNDI related properties the values existing 
in System properties at the time of the replacement are 
being found in the cache, so the original values are not 
being looked up.

Since setProperty just puts the new value into the 
System properties but doesn't change the cache Map, 
any changes to the JNDI properties afterwards 
(regardless of the reason) remain unseen for all the 
outside code that uses System.getProperty.

Even worse, JNDI properties not existing during the 
initialisation phase are being cached with null values.

A real life example of a problem: Borland's visibroker 
during its own initialisation reads all the keys, iterates 
through them and saves alltogether into its own 
Hashtable. JNDI properties with null values cause it to 
break, since Hashtable doesn't allow neither null keys 
nor values.

Regardless of the fact if visibroker does it right not 
checking the values before putting them into a 
Hashtable, turning JNDI properties into read-only 
doesn't feel right.

----------------------------------------------------------------------

>Comment By: Scott M Stark (starksm)
Date: 2003-08-24 05:12

Message:
Logged In: YES 
user_id=175228

The setProperty override has been updated to allow updates
to the JNDI cached properties for the 3.2.2RC3 release.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=791195&group_id=22866


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to