You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "matt hoffman (JIRA)" <ji...@apache.org> on 2006/05/02 15:54:38 UTC
[jira] Created: (AMQ-704) ActiveIO compromises
java.lang.System.properties
ActiveIO compromises java.lang.System.properties
------------------------------------------------
Key: AMQ-704
URL: https://issues.apache.org/activemq/browse/AMQ-704
Project: ActiveMQ
Type: Bug
Environment: ActiveMQ 4.0RC2 (confirmed still around in the current ActiveIO SVN), Java 1.5 on Windows (but should be a problem anywhere).
Reporter: matt hoffman
Fix For: 4.0 RC2
When using the ActiveIO journal, it's putting a java.util.HashSet into the System.properties (using a properties.put() call that circumvents the normal System.putProperty() method, that only allows strings). This isn't allowed, according to java.util.Properties' contract, and therefore breaks other packages that rely on System.properties adhering to its contract. Most notably, it chokes Hibernate; however, anything that iterates through the System properties will fail after ActiveIO has compromised it with a non-String value.
Honestly, I don't know why Properties doesn't allow non-String values, but oh well. From the java.lang.Properties docs:
"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."
The call is being made in org.apache.activeio.journal.active.ControlFile; I suppose a hack could be created that stringifies the HashSet before placing it in the properties and recreates it before getting it out again; atlernately, a simple singleton or static set could be used. I'd be happy to implement either one, if you'd like.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-704) ActiveIO compromises
java.lang.System.properties
Posted by "Jamie McCrindle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-704?page=comments#action_36942 ]
Jamie McCrindle commented on AMQ-704:
-------------------------------------
hi, is this really fixed or is the workaround considered the fix? if it's just the workaround, it's not great, since it fries hibernate 3.1 without the workaround. the workaround is pretty difficult to find and the setting of the DisableLocking system property is not a particularly friendly solution (especially if you don't want locking disabled).
> ActiveIO compromises java.lang.System.properties
> ------------------------------------------------
>
> Key: AMQ-704
> URL: https://issues.apache.org/activemq/browse/AMQ-704
> Project: ActiveMQ
> Issue Type: Bug
> Environment: ActiveMQ 4.0RC2 (confirmed still around in the current ActiveIO SVN), Java 1.5 on Windows (but should be a problem anywhere).
> Reporter: matt hoffman
> Assigned To: Hiram Chirino
> Fix For: 4.0
>
>
> When using the ActiveIO journal, it's putting a java.util.HashSet into the System.properties (using a properties.put() call that circumvents the normal System.putProperty() method, that only allows strings). This isn't allowed, according to java.util.Properties' contract, and therefore breaks other packages that rely on System.properties adhering to its contract. Most notably, it chokes Hibernate; however, anything that iterates through the System properties will fail after ActiveIO has compromised it with a non-String value.
> Honestly, I don't know why Properties doesn't allow non-String values, but oh well. From the java.lang.Properties docs:
> "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."
> The call is being made in org.apache.activeio.journal.active.ControlFile; I suppose a hack could be created that stringifies the HashSet before placing it in the properties and recreates it before getting it out again; atlernately, a simple singleton or static set could be used. I'd be happy to implement either one, if you'd like.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-704) ActiveIO compromises
java.lang.System.properties
Posted by "Hiram Chirino (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-704?page=all ]
Hiram Chirino updated AMQ-704:
------------------------------
Fix Version: 4.1
(was: 4.0 RC2)
> ActiveIO compromises java.lang.System.properties
> ------------------------------------------------
>
> Key: AMQ-704
> URL: https://issues.apache.org/activemq/browse/AMQ-704
> Project: ActiveMQ
> Type: Bug
> Environment: ActiveMQ 4.0RC2 (confirmed still around in the current ActiveIO SVN), Java 1.5 on Windows (but should be a problem anywhere).
> Reporter: matt hoffman
> Assignee: Hiram Chirino
> Fix For: 4.1
>
>
> When using the ActiveIO journal, it's putting a java.util.HashSet into the System.properties (using a properties.put() call that circumvents the normal System.putProperty() method, that only allows strings). This isn't allowed, according to java.util.Properties' contract, and therefore breaks other packages that rely on System.properties adhering to its contract. Most notably, it chokes Hibernate; however, anything that iterates through the System properties will fail after ActiveIO has compromised it with a non-String value.
> Honestly, I don't know why Properties doesn't allow non-String values, but oh well. From the java.lang.Properties docs:
> "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."
> The call is being made in org.apache.activeio.journal.active.ControlFile; I suppose a hack could be created that stringifies the HashSet before placing it in the properties and recreates it before getting it out again; atlernately, a simple singleton or static set could be used. I'd be happy to implement either one, if you'd like.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-704) ActiveIO compromises
java.lang.System.properties
Posted by "Hiram Chirino (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-704?page=all ]
Hiram Chirino reassigned AMQ-704:
---------------------------------
Assign To: Hiram Chirino
> ActiveIO compromises java.lang.System.properties
> ------------------------------------------------
>
> Key: AMQ-704
> URL: https://issues.apache.org/activemq/browse/AMQ-704
> Project: ActiveMQ
> Type: Bug
> Environment: ActiveMQ 4.0RC2 (confirmed still around in the current ActiveIO SVN), Java 1.5 on Windows (but should be a problem anywhere).
> Reporter: matt hoffman
> Assignee: Hiram Chirino
> Fix For: 4.0 RC2
>
>
> When using the ActiveIO journal, it's putting a java.util.HashSet into the System.properties (using a properties.put() call that circumvents the normal System.putProperty() method, that only allows strings). This isn't allowed, according to java.util.Properties' contract, and therefore breaks other packages that rely on System.properties adhering to its contract. Most notably, it chokes Hibernate; however, anything that iterates through the System properties will fail after ActiveIO has compromised it with a non-String value.
> Honestly, I don't know why Properties doesn't allow non-String values, but oh well. From the java.lang.Properties docs:
> "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."
> The call is being made in org.apache.activeio.journal.active.ControlFile; I suppose a hack could be created that stringifies the HashSet before placing it in the properties and recreates it before getting it out again; atlernately, a simple singleton or static set could be used. I'd be happy to implement either one, if you'd like.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-704) ActiveIO compromises
java.lang.System.properties
Posted by "Hiram Chirino (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-704?page=comments#action_36140 ]
Hiram Chirino commented on AMQ-704:
-----------------------------------
The reason the singleton map was put in the System properties were chosen in the first place is because it's guaranteed to be in the primordial classloader and can be acessed by all classloaders. Putting a singleton in a static class field would now produce a system wide singleton if multiple classloaders are in use for the class that is holding the static hashmap.
Do we know of any other locations that we can register a JVM wide object that is accessible by all classloaders?
Stringifing the map sounds promising if a bit in-efficient. But then again locking is not a fast thing right?
For now, activeio has implemented a workaround. Add a -Dorg.apache.activeio.journal.active.DisableLocking=true to JVM startup options and activeio will avoid using the System properties this way.
> ActiveIO compromises java.lang.System.properties
> ------------------------------------------------
>
> Key: AMQ-704
> URL: https://issues.apache.org/activemq/browse/AMQ-704
> Project: ActiveMQ
> Type: Bug
> Environment: ActiveMQ 4.0RC2 (confirmed still around in the current ActiveIO SVN), Java 1.5 on Windows (but should be a problem anywhere).
> Reporter: matt hoffman
> Fix For: 4.0 RC2
>
>
> When using the ActiveIO journal, it's putting a java.util.HashSet into the System.properties (using a properties.put() call that circumvents the normal System.putProperty() method, that only allows strings). This isn't allowed, according to java.util.Properties' contract, and therefore breaks other packages that rely on System.properties adhering to its contract. Most notably, it chokes Hibernate; however, anything that iterates through the System properties will fail after ActiveIO has compromised it with a non-String value.
> Honestly, I don't know why Properties doesn't allow non-String values, but oh well. From the java.lang.Properties docs:
> "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."
> The call is being made in org.apache.activeio.journal.active.ControlFile; I suppose a hack could be created that stringifies the HashSet before placing it in the properties and recreates it before getting it out again; atlernately, a simple singleton or static set could be used. I'd be happy to implement either one, if you'd like.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-704) ActiveIO compromises
java.lang.System.properties
Posted by "Hiram Chirino (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-704?page=all ]
Hiram Chirino resolved AMQ-704:
-------------------------------
Fix Version: 4.0
(was: 4.1)
Resolution: Fixed
You can now use the -Dorg.apache.activeio.journal.active.DisableLocking=true option to disable the activeio locking trick.
> ActiveIO compromises java.lang.System.properties
> ------------------------------------------------
>
> Key: AMQ-704
> URL: https://issues.apache.org/activemq/browse/AMQ-704
> Project: ActiveMQ
> Type: Bug
> Environment: ActiveMQ 4.0RC2 (confirmed still around in the current ActiveIO SVN), Java 1.5 on Windows (but should be a problem anywhere).
> Reporter: matt hoffman
> Assignee: Hiram Chirino
> Fix For: 4.0
>
>
> When using the ActiveIO journal, it's putting a java.util.HashSet into the System.properties (using a properties.put() call that circumvents the normal System.putProperty() method, that only allows strings). This isn't allowed, according to java.util.Properties' contract, and therefore breaks other packages that rely on System.properties adhering to its contract. Most notably, it chokes Hibernate; however, anything that iterates through the System properties will fail after ActiveIO has compromised it with a non-String value.
> Honestly, I don't know why Properties doesn't allow non-String values, but oh well. From the java.lang.Properties docs:
> "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."
> The call is being made in org.apache.activeio.journal.active.ControlFile; I suppose a hack could be created that stringifies the HashSet before placing it in the properties and recreates it before getting it out again; atlernately, a simple singleton or static set could be used. I'd be happy to implement either one, if you'd like.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira