Changing system properties from web applications

[mwomack]

What is the default behavior/configuration for JBoss when a web application changes a system property? Is the change propagated to the container and other deployed web applications or is it isolated to just that web application? Is is possible to configure this behavior?

-Mark

[danl_thompson]

If I understand the Sun documentation, system properties is populated when the JVM starts, and thus changes to the system properties by the application stay within the system properties of the application.

I have some parts of our system that requires certain system properties to be set, and I actaully set them in an MBean which is loaded as a SAR before the rest of the system is loaded... so I can get complete control over the values this way, even at run-time.

This also has the benefit of moving the init values out of the environment variables or some evil batch scirpt, and putting them into the jboss-service.xml for the MBean.

dt

[starksm64]

System properties are global to the jvm and changes are seen by all deployed components. All you can do is prevent them from being modified by running with a security manager.

[mwomack]

Thanks for the quick replies.

This issue I am looking at is the default transform and parser classes that are set by the system properties "javax.xml.transform.TransformerFactory" and "javax.xml.parsers.SAXParserFactory" used by the JAX-RPC factories. Our web application changes these values locally to the classes it wants to use, but if it leaves those values in place, then JBoss appears to have issues later because it is now using the classes the web app specified. And briefly changing the values of those properties could have effects in other threads that access the values in the same time frame.

It just seems strange to me that this kind of change is not isolated from the container and other deployed web apps. Is there another way this should be handled? How can web apps specify a different default set of classes to use for XML related activity?

thanks,
-Mark

[starksm64]

Uh, show me the magic to make System.getProperty a function of the calling context that does not violate the jdk license.

Otherwise, read the jaxp DocumentBuilderFactory.newInstance javadoc and try to use a configuration mechanism that has a quality which is not global in character.

public static DocumentBuilderFactory newInstance()
throws FactoryConfigurationError

Obtain a new instance of a DocumentBuilderFactory. This static method creates a new factory instance. This method uses the following ordered lookup procedure to determine the DocumentBuilderFactory implementation class to load:

* Use the javax.xml.parsers.DocumentBuilderFactory system property.
* Use the properties file "lib/jaxp.properties" in the JRE directory. This configuration file is in standard java.util.Properties format and contains the fully qualified name of the implementation class with the key being the system property defined above.
* Use the Services API (as detailed in the JAR specification), if available, to determine the classname. The Services API will look for a classname in the file META-INF/services/javax.xml.parsers.DocumentBuilderFactory in jars available to the runtime.
* Platform default DocumentBuilderFactory instance.

Once an application has obtained a reference to a DocumentBuilderFactory it can use the factory to configure and obtain parser instances.