[JBoss JIRA] (WFLY-10448) Obsolete java options -d32, -d64 in jdk-10 affect scripts domain.sh, standalone.sh, appclient.sh
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10448?page=com.atlassian.jira.plugin... ]
Brian Stansberry edited comment on WFLY-10448 at 5/24/18 6:14 PM:
------------------------------------------------------------------
AIUI, any -d32 or -d64 would only come from user supplied $JAVA_OPTS. And the presence of that in $JAVA_OPTS is going to prevent the server starting, which is fine, the user should be informed if they are providing useless params. So, the script missing out on including a -server doesn't matter much.
Adding a -d32 in domain.conf and running domain.sh I get:
{code}
$ dist/target/wildfly-13.0.0.Beta2-SNAPSHOT/bin/domain.sh
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /Users/bstansberry/dev/wildfly/wildfly/dist/target/wildfly-13.0.0.Beta2-SNAPSHOT
JAVA: /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/bin/java
JAVA_OPTS: -d32 -Xms64m -Xmx512m -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
=========================================================================
Error: This Java instance does not support a 32-bit JVM.
Please install the desired version.
{code}
In standalone.sh it's a bit different as there's this crufty stuff:
{code}
elif $darwin && [ "x$SERVER_SET" = "x" ]; then
# Use 32-bit on Mac, unless server has been specified or the user opts are incompatible
"$JAVA" -d32 $JAVA_OPTS -version > /dev/null 2>&1 && PREPEND_JAVA_OPTS="-d32" && JVM_OPTVERSION="-d32"
fi
{code}
There we're trying 'java -d32 -version' regardless of what the user says. It doesn't seem to break anything (in fact that call failing 'works', as it results as intended in not trying to pass -d32 in the java call that launches the server.)
OT: in 2018 this logic trying to force Macs to use -client and -d32 seems really crufty and not worth the complexity. Note also that standalone.sh doesn't actively prevent -server for Macs the way domain.sh and appclient.sh do.
Semi-OT: In the script snippet in the description I see two smelly things:
1) HAS_HOTSPOT=`"$JAVA" $JVM_OPTVERSION -version 2>&1 | $GREP -i HotSpot`
That '-version' is redundant as JVM_OPTVERSION already has -version in it. The JVM doesn't seem to mind the duplicate though, at least Hotspot doesn't.
2) The last block is pointless as JVM_OPTVERSION is not used after it:
{code}
else
JVM_OPTVERSION="-server $JVM_OPTVERSION"
fi
{code}
was (Author: brian.stansberry):
AIUI, any -d32 or -d64 would only come from user supplied $JAVA_OPTS. And the presence of that in $JAVA_OPTS is going to prevent the server starting, which is fine, the user should be informed if they are providing useless params. So, the script missing out on including a -server doesn't matter much.
Adding a -d32 in domain.conf and running domain.sh I get:
{code}
$ dist/target/wildfly-13.0.0.Beta2-SNAPSHOT/bin/domain.sh
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /Users/bstansberry/dev/wildfly/wildfly/dist/target/wildfly-13.0.0.Beta2-SNAPSHOT
JAVA: /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/bin/java
JAVA_OPTS: -d32 -Xms64m -Xmx512m -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
=========================================================================
Error: This Java instance does not support a 32-bit JVM.
Please install the desired version.
{code}
In standalone.sh it's a bit different as there's this crufty stuff:
{code}
elif $darwin && [ "x$SERVER_SET" = "x" ]; then
# Use 32-bit on Mac, unless server has been specified or the user opts are incompatible
"$JAVA" -d32 $JAVA_OPTS -version > /dev/null 2>&1 && PREPEND_JAVA_OPTS="-d32" && JVM_OPTVERSION="-d32"
fi
{code}
There we're trying 'java -d32 -version' regardless of what the user says. It doesn't seem to break anything (in fact that calling failing 'works', as it results in not trying to pass -d32 in the java call that launches the server.)
OT: in 2018 this logic trying to force Macs to use -client and -d32 seems really crufty and not worth the complexity. Note also that standalone.sh doesn't actively prevent -server for Macs the way domain.sh and appclient.sh do.
Semi-OT: In the script snippet in the description I see two smelly things:
1) HAS_HOTSPOT=`"$JAVA" $JVM_OPTVERSION -version 2>&1 | $GREP -i HotSpot`
That '-version' is redundant as JVM_OPTVERSION already has -version in it. The JVM doesn't seem to mind the duplicate though, at least Hotspot doesn't.
2) The last block is pointless as JVM_OPTVERSION is not used after it:
{code}
else
JVM_OPTVERSION="-server $JVM_OPTVERSION"
fi
{code}
> Obsolete java options -d32, -d64 in jdk-10 affect scripts domain.sh, standalone.sh, appclient.sh
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-10448
> URL: https://issues.jboss.org/browse/WFLY-10448
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 13.0.0.CR1
> Reporter: R Searls
> Assignee: R Searls
> Priority: Minor
>
> bin\scripts domain.sh, standalone.sh and appclient.sh have a section of code that uses java option -d32 and -d64 when calling java to check the HotSpot type. These 2 options have been removed from JDK-10. They are marked as deprecated in JDK-9 but still function.
> These options are used in determining if '-server' is added to JAVA_OPTS. Enhancements need to be made to the scripts to check the JDK version and take appropriate action is assigning the value '-server'.
> The code affected
> {code:java}
> # Check for -d32/-d64 in JAVA_OPTS
> JVM_OPTVERSION="-version"
> JVM_D64_OPTION=`echo $JAVA_OPTS | $GREP "\-d64"`
> JVM_D32_OPTION=`echo $JAVA_OPTS | $GREP "\-d32"`
> test "x$JVM_D64_OPTION" != "x" && JVM_OPTVERSION="-d64 $JVM_OPTVERSION"
> test "x$JVM_D32_OPTION" != "x" && JVM_OPTVERSION="-d32 $JVM_OPTVERSION"
> # If -server not set in JAVA_OPTS, set it, if supported
> SERVER_SET=`echo $JAVA_OPTS | $GREP "\-server"`
> if [ "x$SERVER_SET" = "x" ]; then
> # Check for SUN(tm) JVM w/ HotSpot support
> if [ "x$HAS_HOTSPOT" = "x" ]; then
> HAS_HOTSPOT=`"$JAVA" $JVM_OPTVERSION -version 2>&1 | $GREP -i HotSpot`
> fi
> # Check for OpenJDK JVM w/server support
> if [ "x$HAS_OPENJDK" = "x" ]; then
> HAS_OPENJDK=`"$JAVA" $JVM_OPTVERSION 2>&1 | $GREP -i OpenJDK`
> fi
> # Check for IBM JVM w/server support
> if [ "x$HAS_IBM" = "x" ]; then
> HAS_IBM=`"$JAVA" $JVM_OPTVERSION 2>&1 | $GREP -i "IBM J9"`
> fi
> # Enable -server if we have Hotspot or OpenJDK, unless we can't
> if [ "x$HAS_HOTSPOT" != "x" -o "x$HAS_OPENJDK" != "x" -o "x$HAS_IBM" != "x" ]; then
> # MacOS does not support -server flag
> if [ "$darwin" != "true" ]; then
> PROCESS_CONTROLLER_JAVA_OPTS="-server $PROCESS_CONTROLLER_JAVA_OPTS"
> HOST_CONTROLLER_JAVA_OPTS="-server $HOST_CONTROLLER_JAVA_OPTS"
> JVM_OPTVERSION="-server $JVM_OPTVERSION"
> fi
> fi
> else
> JVM_OPTVERSION="-server $JVM_OPTVERSION"
> fi
> {code}
> Here is the output of the currently supported java versions
> Doc for jdk-8 states
> > java -help
> where options include:
> -d32 use a 32-bit data model if available
> -d64 use a 64-bit data model if available
> Using these options tell if the version supports 32-bit or 64-bit
> > java -d32 -version
> Error: This Java instance does not support a 32-bit JVM.
> Please install the desired version.
> > java -d64 -version
> java version "1.8.0_72"
> Java(TM) SE Runtime Environment (build 1.8.0_72-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 25.72-b15, mixed mode)
> Doc for jdk-9 states
> > java -help
> where options include:
> -d32 Deprecated, will be removed in a future release
> -d64 Deprecated, will be removed in a future release
> > java -d32 -version
> Error: This Java instance does not support a 32-bit JVM.
> Please install the desired version.
> > java -d64 -version
> openjdk version "9.0.4"
> OpenJDK Runtime Environment (build 9.0.4+11)
> OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode)
> Doc for jdk-10
> > java -help
> No documentation for these options listed
> > java -d32 -version
> Unrecognized option: -d32
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> > java -d64 -version
> Unrecognized option: -d64
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Obsolete java options -d32, -d64 in jdk-10 affect scripts domain.sh, standalone.sh
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10448) Obsolete java options -d32, -d64 in jdk-10 affect scripts domain.sh, standalone.sh, appclient.sh
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10448?page=com.atlassian.jira.plugin... ]
Brian Stansberry edited comment on WFLY-10448 at 5/24/18 6:11 PM:
------------------------------------------------------------------
AIUI, any -d32 or -d64 would only come from user supplied $JAVA_OPTS. And the presence of that in $JAVA_OPTS is going to prevent the server starting, which is fine, the user should be informed if they are providing useless params. So, the script missing out on including a -server doesn't matter much.
Adding a -d32 in domain.conf and running domain.sh I get:
{code}
$ dist/target/wildfly-13.0.0.Beta2-SNAPSHOT/bin/domain.sh
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /Users/bstansberry/dev/wildfly/wildfly/dist/target/wildfly-13.0.0.Beta2-SNAPSHOT
JAVA: /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/bin/java
JAVA_OPTS: -d32 -Xms64m -Xmx512m -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
=========================================================================
Error: This Java instance does not support a 32-bit JVM.
Please install the desired version.
{code}
In standalone.sh it's a bit different as there's this crufty stuff:
{code}
elif $darwin && [ "x$SERVER_SET" = "x" ]; then
# Use 32-bit on Mac, unless server has been specified or the user opts are incompatible
"$JAVA" -d32 $JAVA_OPTS -version > /dev/null 2>&1 && PREPEND_JAVA_OPTS="-d32" && JVM_OPTVERSION="-d32"
fi
{code}
There we're trying 'java -d32 -version' regardless of what the user says. It doesn't seem to break anything (in fact that calling failing 'works', as it results in not trying to pass -d32 in the java call that launches the server.)
OT: in 2018 this logic trying to force Macs to use -client and -d32 seems really crufty and not worth the complexity. Note also that standalone.sh doesn't actively prevent -server for Macs the way domain.sh and appclient.sh do.
Semi-OT: In the script snippet in the description I see two smelly things:
1) HAS_HOTSPOT=`"$JAVA" $JVM_OPTVERSION -version 2>&1 | $GREP -i HotSpot`
That '-version' is redundant as JVM_OPTVERSION already has -version in it. The JVM doesn't seem to mind the duplicate though, at least Hotspot doesn't.
2) The last block is pointless as JVM_OPTVERSION is not used after it:
{code}
else
JVM_OPTVERSION="-server $JVM_OPTVERSION"
fi
{code}
was (Author: brian.stansberry):
AIUI, any -d32 or -d64 would only come from user supplied $JAVA_OPTS. And the presence of that in $JAVA_OPTS is going to prevent the server starting, which is fine, the user should be informed if they are providing useless params. So, the absence of a -server doesn't matter much.
Adding a -d32 in domain.conf and running domain.sh I get:
{code}
$ dist/target/wildfly-13.0.0.Beta2-SNAPSHOT/bin/domain.sh
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /Users/bstansberry/dev/wildfly/wildfly/dist/target/wildfly-13.0.0.Beta2-SNAPSHOT
JAVA: /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/bin/java
JAVA_OPTS: -d32 -Xms64m -Xmx512m -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
=========================================================================
Error: This Java instance does not support a 32-bit JVM.
Please install the desired version.
{code}
In standalone.sh it's a bit different as there's this crufty stuff:
{code}
elif $darwin && [ "x$SERVER_SET" = "x" ]; then
# Use 32-bit on Mac, unless server has been specified or the user opts are incompatible
"$JAVA" -d32 $JAVA_OPTS -version > /dev/null 2>&1 && PREPEND_JAVA_OPTS="-d32" && JVM_OPTVERSION="-d32"
fi
{code}
There we're trying 'java -d32 -version' regardless of what the user says. It doesn't seem to break anything (in fact that calling failing 'works', as it results in not trying to pass -d32 in the java call that launches the server.)
OT: in 2018 this logic trying to force Macs to use -client and -d32 seems really crufty and not worth the complexity. Note also that standalone.sh doesn't actively prevent -server for Macs the way domain.sh and appclient.sh do.
Semi-OT: In the script snippet in the description I see two smelly things:
1) HAS_HOTSPOT=`"$JAVA" $JVM_OPTVERSION -version 2>&1 | $GREP -i HotSpot`
That '-version' is redundant as JVM_OPTVERSION already has -version in it. The JVM doesn't seem to mind the duplicate though, at least Hotspot doesn't.
2) The last block is pointless as JVM_OPTVERSION is not used after it:
{code}
else
JVM_OPTVERSION="-server $JVM_OPTVERSION"
fi
{code}
> Obsolete java options -d32, -d64 in jdk-10 affect scripts domain.sh, standalone.sh, appclient.sh
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-10448
> URL: https://issues.jboss.org/browse/WFLY-10448
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 13.0.0.CR1
> Reporter: R Searls
> Assignee: R Searls
> Priority: Minor
>
> bin\scripts domain.sh, standalone.sh and appclient.sh have a section of code that uses java option -d32 and -d64 when calling java to check the HotSpot type. These 2 options have been removed from JDK-10. They are marked as deprecated in JDK-9 but still function.
> These options are used in determining if '-server' is added to JAVA_OPTS. Enhancements need to be made to the scripts to check the JDK version and take appropriate action is assigning the value '-server'.
> The code affected
> {code:java}
> # Check for -d32/-d64 in JAVA_OPTS
> JVM_OPTVERSION="-version"
> JVM_D64_OPTION=`echo $JAVA_OPTS | $GREP "\-d64"`
> JVM_D32_OPTION=`echo $JAVA_OPTS | $GREP "\-d32"`
> test "x$JVM_D64_OPTION" != "x" && JVM_OPTVERSION="-d64 $JVM_OPTVERSION"
> test "x$JVM_D32_OPTION" != "x" && JVM_OPTVERSION="-d32 $JVM_OPTVERSION"
> # If -server not set in JAVA_OPTS, set it, if supported
> SERVER_SET=`echo $JAVA_OPTS | $GREP "\-server"`
> if [ "x$SERVER_SET" = "x" ]; then
> # Check for SUN(tm) JVM w/ HotSpot support
> if [ "x$HAS_HOTSPOT" = "x" ]; then
> HAS_HOTSPOT=`"$JAVA" $JVM_OPTVERSION -version 2>&1 | $GREP -i HotSpot`
> fi
> # Check for OpenJDK JVM w/server support
> if [ "x$HAS_OPENJDK" = "x" ]; then
> HAS_OPENJDK=`"$JAVA" $JVM_OPTVERSION 2>&1 | $GREP -i OpenJDK`
> fi
> # Check for IBM JVM w/server support
> if [ "x$HAS_IBM" = "x" ]; then
> HAS_IBM=`"$JAVA" $JVM_OPTVERSION 2>&1 | $GREP -i "IBM J9"`
> fi
> # Enable -server if we have Hotspot or OpenJDK, unless we can't
> if [ "x$HAS_HOTSPOT" != "x" -o "x$HAS_OPENJDK" != "x" -o "x$HAS_IBM" != "x" ]; then
> # MacOS does not support -server flag
> if [ "$darwin" != "true" ]; then
> PROCESS_CONTROLLER_JAVA_OPTS="-server $PROCESS_CONTROLLER_JAVA_OPTS"
> HOST_CONTROLLER_JAVA_OPTS="-server $HOST_CONTROLLER_JAVA_OPTS"
> JVM_OPTVERSION="-server $JVM_OPTVERSION"
> fi
> fi
> else
> JVM_OPTVERSION="-server $JVM_OPTVERSION"
> fi
> {code}
> Here is the output of the currently supported java versions
> Doc for jdk-8 states
> > java -help
> where options include:
> -d32 use a 32-bit data model if available
> -d64 use a 64-bit data model if available
> Using these options tell if the version supports 32-bit or 64-bit
> > java -d32 -version
> Error: This Java instance does not support a 32-bit JVM.
> Please install the desired version.
> > java -d64 -version
> java version "1.8.0_72"
> Java(TM) SE Runtime Environment (build 1.8.0_72-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 25.72-b15, mixed mode)
> Doc for jdk-9 states
> > java -help
> where options include:
> -d32 Deprecated, will be removed in a future release
> -d64 Deprecated, will be removed in a future release
> > java -d32 -version
> Error: This Java instance does not support a 32-bit JVM.
> Please install the desired version.
> > java -d64 -version
> openjdk version "9.0.4"
> OpenJDK Runtime Environment (build 9.0.4+11)
> OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode)
> Doc for jdk-10
> > java -help
> No documentation for these options listed
> > java -d32 -version
> Unrecognized option: -d32
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> > java -d64 -version
> Unrecognized option: -d64
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Obsolete java options -d32, -d64 in jdk-10 affect scripts domain.sh, standalone.sh
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10448) Obsolete java options -d32, -d64 in jdk-10 affect scripts domain.sh, standalone.sh, appclient.sh
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10448?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-10448:
-----------------------------------------
AIUI, any -d32 or -d64 would only come from user supplied $JAVA_OPTS. And the presence of that in $JAVA_OPTS is going to prevent the server starting, which is fine, the user should be informed if they are providing useless params. So, the absence of a -server doesn't matter much.
Adding a -d32 in domain.conf and running domain.sh I get:
{code}
$ dist/target/wildfly-13.0.0.Beta2-SNAPSHOT/bin/domain.sh
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /Users/bstansberry/dev/wildfly/wildfly/dist/target/wildfly-13.0.0.Beta2-SNAPSHOT
JAVA: /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/bin/java
JAVA_OPTS: -d32 -Xms64m -Xmx512m -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
=========================================================================
Error: This Java instance does not support a 32-bit JVM.
Please install the desired version.
{code}
In standalone.sh it's a bit different as there's this crufty stuff:
{code}
elif $darwin && [ "x$SERVER_SET" = "x" ]; then
# Use 32-bit on Mac, unless server has been specified or the user opts are incompatible
"$JAVA" -d32 $JAVA_OPTS -version > /dev/null 2>&1 && PREPEND_JAVA_OPTS="-d32" && JVM_OPTVERSION="-d32"
fi
{code}
There we're trying 'java -d32 -version' regardless of what the user says. It doesn't seem to break anything (in fact that calling failing 'works', as it results in not trying to pass -d32 in the java call that launches the server.)
OT: in 2018 this logic trying to force Macs to use -client and -d32 seems really crufty and not worth the complexity. Note also that standalone.sh doesn't actively prevent -server for Macs the way domain.sh and appclient.sh do.
Semi-OT: In the script snippet in the description I see two smelly things:
1) HAS_HOTSPOT=`"$JAVA" $JVM_OPTVERSION -version 2>&1 | $GREP -i HotSpot`
That '-version' is redundant as JVM_OPTVERSION already has -version in it. The JVM doesn't seem to mind the duplicate though, at least Hotspot doesn't.
2) The last block is pointless as JVM_OPTVERSION is not used after it:
{code}
else
JVM_OPTVERSION="-server $JVM_OPTVERSION"
fi
{code}
> Obsolete java options -d32, -d64 in jdk-10 affect scripts domain.sh, standalone.sh, appclient.sh
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-10448
> URL: https://issues.jboss.org/browse/WFLY-10448
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 13.0.0.CR1
> Reporter: R Searls
> Assignee: R Searls
> Priority: Minor
>
> bin\scripts domain.sh, standalone.sh and appclient.sh have a section of code that uses java option -d32 and -d64 when calling java to check the HotSpot type. These 2 options have been removed from JDK-10. They are marked as deprecated in JDK-9 but still function.
> These options are used in determining if '-server' is added to JAVA_OPTS. Enhancements need to be made to the scripts to check the JDK version and take appropriate action is assigning the value '-server'.
> The code affected
> {code:java}
> # Check for -d32/-d64 in JAVA_OPTS
> JVM_OPTVERSION="-version"
> JVM_D64_OPTION=`echo $JAVA_OPTS | $GREP "\-d64"`
> JVM_D32_OPTION=`echo $JAVA_OPTS | $GREP "\-d32"`
> test "x$JVM_D64_OPTION" != "x" && JVM_OPTVERSION="-d64 $JVM_OPTVERSION"
> test "x$JVM_D32_OPTION" != "x" && JVM_OPTVERSION="-d32 $JVM_OPTVERSION"
> # If -server not set in JAVA_OPTS, set it, if supported
> SERVER_SET=`echo $JAVA_OPTS | $GREP "\-server"`
> if [ "x$SERVER_SET" = "x" ]; then
> # Check for SUN(tm) JVM w/ HotSpot support
> if [ "x$HAS_HOTSPOT" = "x" ]; then
> HAS_HOTSPOT=`"$JAVA" $JVM_OPTVERSION -version 2>&1 | $GREP -i HotSpot`
> fi
> # Check for OpenJDK JVM w/server support
> if [ "x$HAS_OPENJDK" = "x" ]; then
> HAS_OPENJDK=`"$JAVA" $JVM_OPTVERSION 2>&1 | $GREP -i OpenJDK`
> fi
> # Check for IBM JVM w/server support
> if [ "x$HAS_IBM" = "x" ]; then
> HAS_IBM=`"$JAVA" $JVM_OPTVERSION 2>&1 | $GREP -i "IBM J9"`
> fi
> # Enable -server if we have Hotspot or OpenJDK, unless we can't
> if [ "x$HAS_HOTSPOT" != "x" -o "x$HAS_OPENJDK" != "x" -o "x$HAS_IBM" != "x" ]; then
> # MacOS does not support -server flag
> if [ "$darwin" != "true" ]; then
> PROCESS_CONTROLLER_JAVA_OPTS="-server $PROCESS_CONTROLLER_JAVA_OPTS"
> HOST_CONTROLLER_JAVA_OPTS="-server $HOST_CONTROLLER_JAVA_OPTS"
> JVM_OPTVERSION="-server $JVM_OPTVERSION"
> fi
> fi
> else
> JVM_OPTVERSION="-server $JVM_OPTVERSION"
> fi
> {code}
> Here is the output of the currently supported java versions
> Doc for jdk-8 states
> > java -help
> where options include:
> -d32 use a 32-bit data model if available
> -d64 use a 64-bit data model if available
> Using these options tell if the version supports 32-bit or 64-bit
> > java -d32 -version
> Error: This Java instance does not support a 32-bit JVM.
> Please install the desired version.
> > java -d64 -version
> java version "1.8.0_72"
> Java(TM) SE Runtime Environment (build 1.8.0_72-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 25.72-b15, mixed mode)
> Doc for jdk-9 states
> > java -help
> where options include:
> -d32 Deprecated, will be removed in a future release
> -d64 Deprecated, will be removed in a future release
> > java -d32 -version
> Error: This Java instance does not support a 32-bit JVM.
> Please install the desired version.
> > java -d64 -version
> openjdk version "9.0.4"
> OpenJDK Runtime Environment (build 9.0.4+11)
> OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode)
> Doc for jdk-10
> > java -help
> No documentation for these options listed
> > java -d32 -version
> Unrecognized option: -d32
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> > java -d64 -version
> Unrecognized option: -d64
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Obsolete java options -d32, -d64 in jdk-10 affect scripts domain.sh, standalone.sh
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10449) [GSS] *7.2.z) Unsecured EJB causes "Multiple security domains" exception
by Derek Horton (JIRA)
Derek Horton created WFLY-10449:
-----------------------------------
Summary: [GSS] *7.2.z) Unsecured EJB causes "Multiple security domains" exception
Key: WFLY-10449
URL: https://issues.jboss.org/browse/WFLY-10449
Project: WildFly
Issue Type: Bug
Components: EJB, Security
Affects Versions: 12.0.0.Final
Reporter: Derek Horton
Assignee: Jan Kalina
Priority: Critical
Fix For: 13.0.0.Beta1
When trying to deploy deployment containing following two EJBs, secured and unsecured, deploying fails with "Multiple security domains not supported" exception:
{code}
21:16:30,089 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."ejb-deployment-1.0-SNAPSHOT.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ejb-deployment-1.0-SNAPSHOT.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "ejb-deployment-1.0-SNAPSHOT.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:150)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0490: Multiple security domains not supported
at org.jboss.as.ejb3.deployment.processors.EJBDefaultSecurityDomainProcessor.deploy(EJBDefaultSecurityDomainProcessor.java:99)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:143)
... 8 more
{code}
This behavior was in JBEAP-9289 considered correct for situation when one EJB references one security domain and the second references second security domain.
It seems unsecured EJB is considered to be using default security domain.
*Workaround:* Need to set unsecured bean secured by adding:
{code}
@PermitAll
@SecurityDomain("other2") // the same as for secured ejb
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10449) [GSS] (7.2.z) Unsecured EJB causes "Multiple security domains" exception
by Derek Horton (JIRA)
[ https://issues.jboss.org/browse/WFLY-10449?page=com.atlassian.jira.plugin... ]
Derek Horton updated WFLY-10449:
--------------------------------
Summary: [GSS] (7.2.z) Unsecured EJB causes "Multiple security domains" exception (was: [GSS] *7.2.z) Unsecured EJB causes "Multiple security domains" exception)
> [GSS] (7.2.z) Unsecured EJB causes "Multiple security domains" exception
> ------------------------------------------------------------------------
>
> Key: WFLY-10449
> URL: https://issues.jboss.org/browse/WFLY-10449
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Affects Versions: 12.0.0.Final
> Reporter: Derek Horton
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 13.0.0.Beta1
>
>
> When trying to deploy deployment containing following two EJBs, secured and unsecured, deploying fails with "Multiple security domains not supported" exception:
> {code}
> 21:16:30,089 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."ejb-deployment-1.0-SNAPSHOT.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ejb-deployment-1.0-SNAPSHOT.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "ejb-deployment-1.0-SNAPSHOT.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:150)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0490: Multiple security domains not supported
> at org.jboss.as.ejb3.deployment.processors.EJBDefaultSecurityDomainProcessor.deploy(EJBDefaultSecurityDomainProcessor.java:99)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:143)
> ... 8 more
> {code}
> This behavior was in JBEAP-9289 considered correct for situation when one EJB references one security domain and the second references second security domain.
> It seems unsecured EJB is considered to be using default security domain.
> *Workaround:* Need to set unsecured bean secured by adding:
> {code}
> @PermitAll
> @SecurityDomain("other2") // the same as for secured ejb
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10448) Obsolete java options -d32, -d64 in jdk-10 affect scripts domain.sh, standalone.sh, appclient.sh
by R Searls (JIRA)
[ https://issues.jboss.org/browse/WFLY-10448?page=com.atlassian.jira.plugin... ]
R Searls updated WFLY-10448:
----------------------------
Priority: Minor (was: Major)
> Obsolete java options -d32, -d64 in jdk-10 affect scripts domain.sh, standalone.sh, appclient.sh
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-10448
> URL: https://issues.jboss.org/browse/WFLY-10448
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 13.0.0.CR1
> Reporter: R Searls
> Assignee: R Searls
> Priority: Minor
>
> bin\scripts domain.sh, standalone.sh and appclient.sh have a section of code that uses java option -d32 and -d64 when calling java to check the HotSpot type. These 2 options have been removed from JDK-10. They are marked as deprecated in JDK-9 but still function.
> These options are used in determining if '-server' is added to JAVA_OPTS. Enhancements need to be made to the scripts to check the JDK version and take appropriate action is assigning the value '-server'.
> The code affected
> {code:java}
> # Check for -d32/-d64 in JAVA_OPTS
> JVM_OPTVERSION="-version"
> JVM_D64_OPTION=`echo $JAVA_OPTS | $GREP "\-d64"`
> JVM_D32_OPTION=`echo $JAVA_OPTS | $GREP "\-d32"`
> test "x$JVM_D64_OPTION" != "x" && JVM_OPTVERSION="-d64 $JVM_OPTVERSION"
> test "x$JVM_D32_OPTION" != "x" && JVM_OPTVERSION="-d32 $JVM_OPTVERSION"
> # If -server not set in JAVA_OPTS, set it, if supported
> SERVER_SET=`echo $JAVA_OPTS | $GREP "\-server"`
> if [ "x$SERVER_SET" = "x" ]; then
> # Check for SUN(tm) JVM w/ HotSpot support
> if [ "x$HAS_HOTSPOT" = "x" ]; then
> HAS_HOTSPOT=`"$JAVA" $JVM_OPTVERSION -version 2>&1 | $GREP -i HotSpot`
> fi
> # Check for OpenJDK JVM w/server support
> if [ "x$HAS_OPENJDK" = "x" ]; then
> HAS_OPENJDK=`"$JAVA" $JVM_OPTVERSION 2>&1 | $GREP -i OpenJDK`
> fi
> # Check for IBM JVM w/server support
> if [ "x$HAS_IBM" = "x" ]; then
> HAS_IBM=`"$JAVA" $JVM_OPTVERSION 2>&1 | $GREP -i "IBM J9"`
> fi
> # Enable -server if we have Hotspot or OpenJDK, unless we can't
> if [ "x$HAS_HOTSPOT" != "x" -o "x$HAS_OPENJDK" != "x" -o "x$HAS_IBM" != "x" ]; then
> # MacOS does not support -server flag
> if [ "$darwin" != "true" ]; then
> PROCESS_CONTROLLER_JAVA_OPTS="-server $PROCESS_CONTROLLER_JAVA_OPTS"
> HOST_CONTROLLER_JAVA_OPTS="-server $HOST_CONTROLLER_JAVA_OPTS"
> JVM_OPTVERSION="-server $JVM_OPTVERSION"
> fi
> fi
> else
> JVM_OPTVERSION="-server $JVM_OPTVERSION"
> fi
> {code}
> Here is the output of the currently supported java versions
> Doc for jdk-8 states
> > java -help
> where options include:
> -d32 use a 32-bit data model if available
> -d64 use a 64-bit data model if available
> Using these options tell if the version supports 32-bit or 64-bit
> > java -d32 -version
> Error: This Java instance does not support a 32-bit JVM.
> Please install the desired version.
> > java -d64 -version
> java version "1.8.0_72"
> Java(TM) SE Runtime Environment (build 1.8.0_72-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 25.72-b15, mixed mode)
> Doc for jdk-9 states
> > java -help
> where options include:
> -d32 Deprecated, will be removed in a future release
> -d64 Deprecated, will be removed in a future release
> > java -d32 -version
> Error: This Java instance does not support a 32-bit JVM.
> Please install the desired version.
> > java -d64 -version
> openjdk version "9.0.4"
> OpenJDK Runtime Environment (build 9.0.4+11)
> OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode)
> Doc for jdk-10
> > java -help
> No documentation for these options listed
> > java -d32 -version
> Unrecognized option: -d32
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> > java -d64 -version
> Unrecognized option: -d64
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Obsolete java options -d32, -d64 in jdk-10 affect scripts domain.sh, standalone.sh
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10425) With Hibernate ORM 5.3, protect against NPE in WildFlyCustomRegionFactoryInitiator for non-container-managed JPA deployment
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-10425?page=com.atlassian.jira.plugin... ]
Scott Marlow closed WFLY-10425.
-------------------------------
> With Hibernate ORM 5.3, protect against NPE in WildFlyCustomRegionFactoryInitiator for non-container-managed JPA deployment
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10425
> URL: https://issues.jboss.org/browse/WFLY-10425
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 13.0.0.Beta1
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 13.0.0.CR1
>
>
> WildFlyCustomRegionFactoryInitiator needs to test for jpa_shared_code_mode being null.
> {code}
> at org.jboss.as.jpa.hibernate5.service.WildFlyCustomRegionFactoryInitiator.resolveRegionFactory(WildFlyCustomRegionFactoryInitiator.java:44)
> at org.hibernate.cache.internal.RegionFactoryInitiator.initiateService(RegionFactoryInitiator.java:47)
> at org.hibernate.cache.internal.RegionFactoryInitiator.initiateService(RegionFactoryInitiator.java:32)
> at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.initiateService(StandardServiceRegistryImpl.java:94)
> at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:263)
> at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:237)
> at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:214)
> - locked <0x4fcc> (a org.hibernate.boot.registry.internal.StandardServiceRegistryImpl)
> at org.hibernate.boot.internal.MetadataBuilderImpl$MetadataBuildingOptionsImpl.<init>(MetadataBuilderImpl.java:688)
> at org.hibernate.boot.internal.MetadataBuilderImpl.<init>(MetadataBuilderImpl.java:123)
> at org.hibernate.boot.MetadataSources.getMetadataBuilder(MetadataSources.java:136)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:213)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:169)
> at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:76)
> at org.hibernate.jpa.HibernatePersistenceProvider.getEntityManagerFactoryBuilder(HibernatePersistenceProvider.java:179)
> at org.hibernate.jpa.HibernatePersistenceProvider.getEntityManagerFactoryBuilderOrNull(HibernatePersistenceProvider.java:127)
> at org.hibernate.jpa.HibernatePersistenceProvider.getEntityManagerFactoryBuilderOrNull(HibernatePersistenceProvider.java:69)
> at org.hibernate.jpa.HibernatePersistenceProvider.generateSchema(HibernatePersistenceProvider.java:164)
> at javax.persistence.Persistence.generateSchema(Persistence.java:114)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10433) allow JPA apps to disable WildFly JTA platform/2lc initiators for Hibernate ORM 5.3+
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-10433?page=com.atlassian.jira.plugin... ]
Scott Marlow closed WFLY-10433.
-------------------------------
> allow JPA apps to disable WildFly JTA platform/2lc initiators for Hibernate ORM 5.3+
> ------------------------------------------------------------------------------------
>
> Key: WFLY-10433
> URL: https://issues.jboss.org/browse/WFLY-10433
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 13.0.0.CR1
>
>
> Some applications (e.g. Spring) may not want to use the WF 2lc RegionFactoryInitiator + JtaPlatform classes. To accommodate that need, following persistence unit configuration properties will help:
> * wildfly.jpa.jtaplatform will default to true but if set to false, the WildFly JtaPlatform initiator for ORM 5.3+ (WildFlyCustomJtaPlatformInitiator), will not control Jta use in the Hibernate persistence unit (or session factory).
> * wildfly.jpa.regionfactory will default to true but if set to false,the WildFly 2lc cache initiator for ORM (WildFlyCustomRegionFactoryInitiator) will not control 2lc use in the Hibernate persistence unit (or session factory). Instead, the Hibernate ORM 2lc cache initiator will be used.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month