Back to bug 1035232
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Josef Cacek | 2013-11-27 11:07:07 UTC | Blocks | 953259 | |
| Jitka Kozana | 2013-11-27 12:03:13 UTC | CC | jkudrnac | |
| Darran Lofthouse | 2013-11-27 12:13:55 UTC | Status | NEW | ASSIGNED |
| CC | darran.lofthouse | |||
| Assignee | brian.stansberry | darran.lofthouse | ||
| Link ID | JBoss Issue Tracker WFLY-2585 | |||
| Brian Stansberry | 2013-11-27 20:40:07 UTC | Status | ASSIGNED | POST |
| Target Release | --- | EAP 6.2.0 | ||
| CC | brian.stansberry | |||
| Target Milestone | --- | Pending | ||
| Brian Stansberry | 2013-11-27 21:44:35 UTC | Status | POST | ASSIGNED |
| Assignee | darran.lofthouse | brian.stansberry | ||
| Link ID | JBoss Issue Tracker WFLY-2585 | |||
| Brian Stansberry | 2013-11-28 00:32:10 UTC | Status | ASSIGNED | POST |
| Kabir Khan | 2013-11-28 10:06:44 UTC | CC | kkhan | |
| Josef Cacek | 2013-11-28 14:35:48 UTC | Group | atsec | |
| Jimmy Wilson | 2013-11-29 07:00:32 UTC | CC | jawilson | |
| Blocks | 1027004 | |||
| mark yarborough | 2013-11-30 19:19:01 UTC | Target Release | EAP 6.2.0 | EAP 6.2.CP0a |
| Brian Stansberry | 2013-12-02 19:02:37 UTC | Doc Text | Cause: The Host Controller when preparing the set of system properties to pass to a new Server process will use a value of "true" for any property without a value instead of just leaving no value. Consequence: When use of a default security manager is specified for a managed domain using -Djava.security.manager from the command line or in domain.conf, the Host Controller turns that into -Djava.security.manager=true. If a value is specified for that property, the JVM interprets it as being the class name of the Security Manager implementation to use. So the JVM attempts to initialize a class named "true", which fails, resulting in the following error in the console: Error occurred during initialization of VM java.lang.InternalError: Could not create SecurityManager: true Workaround (if any): To use the default Security Manager implementation, specify its class name as the value of the system property: -Djava.security.manager=java.lang.SecurityManager Result: The Host Controller is able to properly start the servers. | |
| Doc Type | Bug Fix | Known Issue | ||
| Dana Mison | 2013-12-03 04:57:05 UTC | CC | dmison | |
| Doc Text | Cause: The Host Controller when preparing the set of system properties to pass to a new Server process will use a value of "true" for any property without a value instead of just leaving no value. Consequence: When use of a default security manager is specified for a managed domain using -Djava.security.manager from the command line or in domain.conf, the Host Controller turns that into -Djava.security.manager=true. If a value is specified for that property, the JVM interprets it as being the class name of the Security Manager implementation to use. So the JVM attempts to initialize a class named "true", which fails, resulting in the following error in the console: Error occurred during initialization of VM java.lang.InternalError: Could not create SecurityManager: true Workaround (if any): To use the default Security Manager implementation, specify its class name as the value of the system property: -Djava.security.manager=java.lang.SecurityManager Result: The Host Controller is able to properly start the servers. | Servers in a managed domain will not launch successfully if they are configured to use a Java Security Manager without specifying the classname of the Security Manager. This is commonly done when using the default Security Manager by specifying `-Djava.security.manager` in either` domain.conf` or as a command line parameter. In this situation servers will fail to launch with the following message: ---- Error occurred during initialization of VM java.lang.InternalError: Could not create SecurityManager: true ---- This occurs because a system property without a value is passed by Host Controllers to their managed servers with the value of `true`. This means that the servers will attempt to use a Java Security Manager with the classname of `true`. To avoid this, explicitly define the classname of the default Security Manager in the configuration as follows: ---- -Djava.security.manager=java.lang.SecurityManager ---- |
||
| Josef Cacek | 2013-12-03 13:21:17 UTC | Blocks | 1036618 | |
| Carlo de Wolf | 2013-12-11 13:58:01 UTC | Blocks | 1040480 | |
| Carlo de Wolf | 2013-12-11 14:01:09 UTC | Target Release | EAP 6.2.CP0a | EAP 6.3.0 |
| CC | cdewolf | |||
| Blocks | 1027004 | |||
| Carlo de Wolf | 2013-12-18 09:14:04 UTC | Blocks | 1044394 | |
| Kabir Khan | 2014-01-07 09:20:34 UTC | Status | POST | MODIFIED |
| Target Milestone | Pending | DR1 | ||
| Kabir Khan | 2014-01-08 12:04:31 UTC | Target Milestone | DR1 | DR0 |
| mark yarborough | 2014-01-14 13:41:57 UTC | CC | myarboro | |
| Summary | EAP Domain mode is not working properly with Security manager | [CCC] (6.3) EAP Domain mode is not working properly with Security manager | ||
| Ondrej Lukas | 2014-01-15 07:59:00 UTC | Blocks | 1053404 | |
| Paul Gier | 2014-02-11 23:53:30 UTC | Status | MODIFIED | ON_QA |
| Dana Mison | 2014-02-12 00:57:51 UTC | CC | dmison | |
| Ondrej Lukas | 2014-02-26 09:48:24 UTC | Status | ON_QA | VERIFIED |
| Josef Cacek | 2014-03-06 14:45:26 UTC | Blocks | 953259 | |
| Lucas Costi | 2014-05-13 01:55:46 UTC | CC | lcosti | |
| Docs Contact | rdickens | lcosti | ||
| Lucas Costi | 2014-05-13 04:27:43 UTC | Doc Text | Servers in a managed domain will not launch successfully if they are configured to use a Java Security Manager without specifying the classname of the Security Manager. This is commonly done when using the default Security Manager by specifying `-Djava.security.manager` in either` domain.conf` or as a command line parameter. In this situation servers will fail to launch with the following message: ---- Error occurred during initialization of VM java.lang.InternalError: Could not create SecurityManager: true ---- This occurs because a system property without a value is passed by Host Controllers to their managed servers with the value of `true`. This means that the servers will attempt to use a Java Security Manager with the classname of `true`. To avoid this, explicitly define the classname of the default Security Manager in the configuration as follows: ---- -Djava.security.manager=java.lang.SecurityManager ---- | Servers in a managed domain would not launch successfully if they were configured to use a Java Security Manager without specifying the classname of the Security Manager. For example, this is commonly done when using the default Security Manager by specifying `-Djava.security.manager` in either` domain.conf` or as a command line parameter. This issue occurred because a system property without a value was passed by Host Controllers to their managed servers with the value of `true`. This meant that the servers would incorrectly attempt to use a Java Security Manager with the classname of `true`. This issue has been fixed in this release by adding extra checks for host controller system properties so that a system property is passed to the managed servers correctly. As a result, using a managed domain and using the default Security Manager by specifying `-Djava.security.manager` should function as expected. |
| Doc Type | Known Issue | Bug Fix | ||
| Scott Mumford | 2014-05-14 02:28:33 UTC | CC | smumford | |
| Doc Text | Servers in a managed domain would not launch successfully if they were configured to use a Java Security Manager without specifying the classname of the Security Manager. For example, this is commonly done when using the default Security Manager by specifying `-Djava.security.manager` in either` domain.conf` or as a command line parameter. This issue occurred because a system property without a value was passed by Host Controllers to their managed servers with the value of `true`. This meant that the servers would incorrectly attempt to use a Java Security Manager with the classname of `true`. This issue has been fixed in this release by adding extra checks for host controller system properties so that a system property is passed to the managed servers correctly. As a result, using a managed domain and using the default Security Manager by specifying `-Djava.security.manager` should function as expected. | In previous versions of JBoss EAP 6, servers in a managed domain would not launch successfully if they were configured to use a Java Security Manager without specifying the classname of the Security Manager. For example, this is commonly done when using the default Security Manager by specifying `-Djava.security.manager` in either` domain.conf` or as a command line parameter. This issue occurred because a system property without a value was passed by Host Controllers to their managed servers with the value of `true`. This meant that the servers would incorrectly attempt to use a Java Security Manager with the classname of `true`. This issue has been fixed in this release by adding extra checks for host controller system properties so that a system property is passed to the managed servers correctly. As a result, using a managed domain and using the default Security Manager by specifying `-Djava.security.manager` should function as expected. |
||
| mark yarborough | 2014-06-28 15:26:29 UTC | Status | VERIFIED | CLOSED |
| Resolution | --- | CURRENTRELEASE | ||
| Last Closed | 2014-06-28 11:26:29 UTC | |||
| Scott Mumford | 2014-07-04 03:05:45 UTC | Flags | needinfo?(brian.stansberry) | |
| Brian Stansberry | 2014-07-07 13:56:59 UTC | CC | jcacek | |
| Flags | needinfo?(jcacek) | |||
| Brian Stansberry | 2014-07-07 13:57:41 UTC | Flags | needinfo?(brian.stansberry) | needinfo- |
| Josef Cacek | 2014-07-08 13:00:29 UTC | Flags | needinfo?(jcacek) | |
| John Skeoch | 2014-07-21 03:11:03 UTC | Group | atsec | |
| CC | jskeoch | |||
| Scott Mumford | 2014-07-21 03:15:46 UTC | Group | redhat |
Back to bug 1035232