[JBoss JIRA] (WFCORE-1114) NPE in DeploymentStatusHandler
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1114?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1114:
-------------------------------------
Fix Version/s: 2.2.0.CR1
> NPE in DeploymentStatusHandler
> ------------------------------
>
> Key: WFCORE-1114
> URL: https://issues.jboss.org/browse/WFCORE-1114
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.2.0.CR1, 3.0.0.Alpha1
>
>
> Saw an NPE in a test run. This is because AbstractDeploymentUnitService.getStatus() references the possibly null 'monitor' field.
> {code}
> org.jboss.as.test.manualmode.deployment.DeploymentScannerOperationTestCase.testStartup: java.lang.AssertionError: null
> at org.jboss.as.test.manualmode.deployment.DeploymentScannerOperationTestCase.testStartup(DeploymentScannerOperationTestCase.java:92)
> ------- Stdout: -------
> 23:55:18,131 INFO [org.wildfly.core.testrunner.Server] (main) Starting container with: /usr/java/jdk1.8.0_65/jre/bin/java -D[Standalone] -javaagent:/store/repository/org/jboss/byteman/byteman/2.2.1/byteman-2.2.1.jar=port:9091,boot:/store/repository/org/jboss/byteman/byteman/2.2.1/byteman-2.2.1.jar,sys:/opt/buildAgent/work/8d74ae55e497982e/testsuite/shared/target/wildfly-core-testsuite-shared-3.0.0.Alpha1-SNAPSHOT.jar -Dorg.jboss.byteman.transform.all -Dorg.jboss.byteman.verbose=true -Dmaven.repo.local=/store/repository -Xmx512m -Djboss.dist=/opt/buildAgent/work/8d74ae55e497982e/testsuite/manualmode/target/wildfly-core -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true -server -Dts.timeout.factor=100 -Djbossas.ts.dir=/opt/buildAgent/work/8d74ae55e497982e/testsuite/manualmode -ea -Dorg.jboss.boot.log.file=/opt/buildAgent/work/8d74ae55e497982e/testsuite/manualmode/target/wildfly-core/standalone/log/server.log -Dlogging.configuration=file:/opt/buildAgent/work/8d74ae55e497982e/testsuite/manualmode/target/wildfly-core/standalone/configuration/logging.properties -jar /opt/buildAgent/work/8d74ae55e497982e/testsuite/manualmode/target/wildfly-core/jboss-modules.jar -mp /opt/buildAgent/work/8d74ae55e497982e/testsuite/manualmode/target/wildfly-core/modules org.jboss.as.standalone -Djboss.home.dir=/opt/buildAgent/work/8d74ae55e497982e/testsuite/manualmode/target/wildfly-core -Djboss.server.base.dir=/opt/buildAgent/work/8d74ae55e497982e/testsuite/manualmode/target/wildfly-core/standalone -Djboss.server.log.dir=/opt/buildAgent/work/8d74ae55e497982e/testsuite/manualmode/target/wildfly-core/standalone/log -Djboss.server.config.dir=/opt/buildAgent/work/8d74ae55e497982e/testsuite/manualmode/target/wildfly-core/standalone/configuration -c=standalone.xml -bmanagement=::1 -Djboss.http.port=8080 -Djboss.bind.address=::1
> 23:55:18,299 INFO [org.xnio] (main) XNIO version 3.3.2.Final
> TransformListener() : accepting requests on localhost:9091
> 23:55:18,427 INFO [org.xnio.nio] (main) XNIO NIO Implementation Version 3.3.2.Final
> 23:55:18,469 INFO [org.jboss.remoting] (main) JBoss Remoting version 4.0.14.Final
> [0m23:55:18,781 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> [0m [0m23:55:19,059 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> [0m [0m23:55:19,150 INFO [org.jboss.as] (MSC service thread 1-4) WFLYSRV0049: WildFly Core 3.0.0.Alpha1-SNAPSHOT "Kenny" starting
> [0m [0m23:55:19,716 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> [0m [0m23:55:19,739 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.3.2.Final
> [0m [0m23:55:19,747 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.3.2.Final
> [0m [0m23:55:19,799 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 4.0.14.Final
> [0m [33m23:55:19,896 WARN [org.jboss.as.domain.http.api.undertow] (MSC service thread 1-4) WFLYDMHTTP0003: Unable to load console module for slot main, disabling console
> [0m [0m23:55:20,084 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[::1]:9990/management
> [0m [0m23:55:20,084 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[::1]:9990
> [0m [0m23:55:20,084 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 3.0.0.Alpha1-SNAPSHOT "Kenny" started in 1710ms - Started 55 of 57 services (15 services are lazy, passive or on-demand)
> [0m [0m23:55:20,610 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 2) WFLYDR0001: Content added at location /opt/buildAgent/work/8d74ae55e497982e/testsuite/manualmode/target/wildfly-core/standalone/data/content/21/5cf647697bfbd1ed32b458a4568c01fb6e8dd6/content
> [0m [0m23:55:20,628 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "deployment-one.jar" (runtime-name: "deployment-one.jar")
> [0m [0m23:55:20,669 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0010: Deployed "deployment-one.jar" (runtime-name : "deployment-one.jar")
> [0m [0m23:55:21,399 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment deployment-one.jar (runtime-name: deployment-one.jar) in 6ms
> [0m [31m23:55:21,403 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("read-attribute") failed - address: ([("deployment" => "deployment-one.jar")]): java.lang.NullPointerException
> at org.jboss.as.server.deployment.AbstractDeploymentUnitService.getStatus(AbstractDeploymentUnitService.java:111)
> at org.jboss.as.server.deployment.DeploymentStatusHandler$1.execute(DeploymentStatusHandler.java:61)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1341)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:207)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:129)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:151)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:147)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:147)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:465)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1111) Expose runtime methods in JMX for resources in domain servers
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1111?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1111:
-------------------------------------
Fix Version/s: 2.2.0.CR1
> Expose runtime methods in JMX for resources in domain servers
> -------------------------------------------------------------
>
> Key: WFCORE-1111
> URL: https://issues.jboss.org/browse/WFCORE-1111
> Project: WildFly Core
> Issue Type: Feature Request
> Components: JMX
> Affects Versions: 2.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 2.2.0.CR1, 3.0.0.Alpha1
>
>
> The JMX subsystem only exposes MBean operations for READ_ONLY management operations on domain servers.
> It should also be possible to expose RUNTIME_ONLY management operations as they only deal with the runtime and do not alter the management model.
> WFLY-5418 is an example of such operations.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1528) EAP 7 with secured management become unavailable after ~8 days
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1528?page=com.atlassian.jira.plugi... ]
Brian Stansberry reopened WFCORE-1528:
--------------------------------------
Re-opening as we may wish to go beyond the PR that has been merged in order to reduce the risk of recurrence of this kind of bug.
> EAP 7 with secured management become unavailable after ~8 days
> --------------------------------------------------------------
>
> Key: WFCORE-1528
> URL: https://issues.jboss.org/browse/WFCORE-1528
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 2.1.0.Final
> Environment: EAP 7.0.0.CR01 2-way ssl over remote https communication
> Reporter: Simeon Pinder
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 3.0.0.Alpha1
>
>
> Appears there may be an EAP 7.0.0.CR01 2-way ssl issue in domain mode.
> Issue discovered by JON QE after testing for 8 days with SSL.
> JON QE did not see the same issue when running identical test against EAP 6.
> Restarting the remote client(JON Agent) did not repair/fix the issue, and only was repaired after EAP instance restarted.
> See BZ https://bugzilla.redhat.com/show_bug.cgi?id=1330180#c0 for more details.
> JON team would like some evaluation done to determine:
> i)if this is EAP 7 issue or
> ii)somehow just a JON issue
> iii)suggestions on what to do when we try to reproduce properly or ways to shorten reproduce cycle.
> This issue could affect GA release schedules.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ELY-476) Arrays clone() does not work in static method of interface for IBM JDK
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-476?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-476:
---------------------------------
I think it's reasonable to expect that the JVM we run on at least conforms to the JLS (see https://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html#jls-10.7 for more information). We should not work around completely broken JVMs.
> Arrays clone() does not work in static method of interface for IBM JDK
> ----------------------------------------------------------------------
>
> Key: ELY-476
> URL: https://issues.jboss.org/browse/ELY-476
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta4
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
>
> It seems IBM JDK has an issue with using clone() method for arrays in static method of interface. Using arrays clone() method causes following exception for IBM JDK:
> {code}
> java.lang.IllegalAccessError: Class org/wildfly/security/password/interfaces/SaltedSimpleDigestPassword illegally accessing "protected" member of class [B
> at org.wildfly.security.password.interfaces.SaltedSimpleDigestPassword.createRaw(SaltedSimpleDigestPassword.java:112)
> ...
> {code}
> Issue affects only direct usage of arrays clone() method from static method of interface.
> Example, calling methodWillFail() will fail with IBM JDK:
> {code}
> public interface SimpleInterface {
> static int[] methodWillFail() {
> int[] array = {1, 2};
> return array.clone();
> }
> }
> {code}
> Workaround is simple. Calling static method of another class using arrays clone() works for IBM JDK 8.
> Example, calling methodWillNotFail() will pass with IBM JDK:
> {code}
> public interface SimpleInterface {
> static int[] methodWillNotFail() {
> return SimpleClass.methodOk();
> }
> }
> public class SimpleClass {
> static int[] methodOk() {
> int[] array = {1, 2};
> return array.clone();
> }
> }
> {code}
> Affected interfaces:
> org.wildfly.security.auth.server.NameRewriter.java
> org.wildfly.security.authz.RoleMapper.java
> org.wildfly.security.password.interfaces.SaltedSimpleDigestPassword.java
> org.wildfly.security.password.interfaces.OneTimePassword.java
> org.wildfly.security.password.interfaces.BSDUnixDESCryptPassword.java
> org.wildfly.security.password.interfaces.BCryptPassword.java
> org.wildfly.security.password.interfaces.SimpleDigestPassword.java
> org.wildfly.security.password.interfaces.DigestPassword.java
> org.wildfly.security.password.interfaces.ScramDigestPassword.java
> org.wildfly.security.ssl.SNIServerSSLContextSelector.java
> This issue causes errors in following test cases running with IBM JDK:
> org.wildfly.security.auth.KeyStoreBackedSecurityRealmTest
> org.wildfly.security.auth.realm.jdbc.PasswordSupportTest
> org.wildfly.security.password.impl.BCryptPasswordTest
> org.wildfly.security.auth.realm.ldap.UserPasswordPasswordUtilTest
> org.wildfly.security.ldap.PasswordSupportSuiteChild
> org.wildfly.security.password.impl.BSDUnixDESCryptTest
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2062) TYPE_STRING does not handle unicode
by Cody Ebberson (JIRA)
[ https://issues.jboss.org/browse/JGRP-2062?page=com.atlassian.jira.plugin.... ]
Cody Ebberson updated JGRP-2062:
--------------------------------
Description:
In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character.
For example, see objectToByteBuffer lines 561-567:
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util....
{{case TYPE_STRING:
String str=(String)obj;
int len=str.length();
ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING);
for(int i=0; i < len; i++)
retval.put((byte)str.charAt(i));
return retval.array();}}
This code will incorrectly encode any String with non ASCII encoding.
There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path.
was:
In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character.
For example, see objectToByteBuffer lines 561-567:
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util....
{{
case TYPE_STRING:
String str=(String)obj;
int len=str.length();
ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING);
for(int i=0; i < len; i++)
retval.put((byte)str.charAt(i));
return retval.array();
}}
This code will incorrectly encode any String with non ASCII encoding.
There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path.
> TYPE_STRING does not handle unicode
> -----------------------------------
>
> Key: JGRP-2062
> URL: https://issues.jboss.org/browse/JGRP-2062
> Project: JGroups
> Issue Type: Bug
> Reporter: Cody Ebberson
> Assignee: Bela Ban
>
> In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character.
> For example, see objectToByteBuffer lines 561-567:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util....
> {{case TYPE_STRING:
> String str=(String)obj;
> int len=str.length();
> ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING);
> for(int i=0; i < len; i++)
> retval.put((byte)str.charAt(i));
> return retval.array();}}
> This code will incorrectly encode any String with non ASCII encoding.
> There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2062) TYPE_STRING does not handle unicode
by Cody Ebberson (JIRA)
Cody Ebberson created JGRP-2062:
-----------------------------------
Summary: TYPE_STRING does not handle unicode
Key: JGRP-2062
URL: https://issues.jboss.org/browse/JGRP-2062
Project: JGroups
Issue Type: Bug
Reporter: Cody Ebberson
Assignee: Bela Ban
In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character.
For example, see objectToByteBuffer lines 561-567:
https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util....
{{
case TYPE_STRING:
String str=(String)obj;
int len=str.length();
ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING);
for(int i=0; i < len; i++)
retval.put((byte)str.charAt(i));
return retval.array();
}}
This code will incorrectly encode any String with non ASCII encoding.
There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (DROOLS-1169) Running drools with OpenJDK9 (10 May 2016) gives "type java.lang.Object cannot be resolved" and "java.io.Serializable cannot be resolved"
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1169?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet edited comment on DROOLS-1169 at 5/10/16 11:30 AM:
--------------------------------------------------------------------
Mario suggested to try the native compiler instead of ECJ, but due to DROOLS-1171 that fails (that config option fails on JDK 8 too).
was (Author: ge0ffrey):
Mario suggested to try the native compiler, but due to DROOLS-1171 that fails (that config option fails on JDK 8 too).
> Running drools with OpenJDK9 (10 May 2016) gives "type java.lang.Object cannot be resolved" and "java.io.Serializable cannot be resolved"
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1169
> URL: https://issues.jboss.org/browse/DROOLS-1169
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
>
> The code below runs perfectly with OpenJDK 8 (and even 6 and 7).
> To reproduce, use JDK 9 ( https://jdk9.java.net/download/ ) and in optaplanner-core, run XStreamXmlSolverFactoryTest [1] (or mostly any other test that builds a DRL file) to get this error:
> {code}
> 15:56:40.229 [main] ERROR o.d.c.k.b.impl.AbstractKieModule - Unable to build KieBaseModel:defaultKieBase
> Rule Compilation error : [Rule name='Conflict']
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (1:0) : The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (1:0) : The type java.io.Serializable cannot be resolved. It is indirectly referenced from required .class files
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (3:337) : Implicit super constructor Object() is undefined for default constructor. Must define an explicit constructor
> org/optaplanner/core/api/solver/Rule_Conflict903142795.java (6:569) : java.lang.Exception cannot be resolved to a type
> java.lang.IllegalStateException: There are errors in a score DRL:
> Error Messages:
> Message [id=1, level=ERROR, path=org/optaplanner/core/api/solver/testdataScoreRules.drl, line=31, column=0
> text=Rule Compilation error The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files
> The type java.io.Serializable cannot be resolved. It is indirectly referenced from required .class files
> Implicit super constructor Object() is undefined for default constructor. Must define an explicit constructor
> java.lang.Exception cannot be resolved to a type]
> {code}
> That tests builds this DRL:
> {code}
> package org.optaplanner.core.api.solver;
> dialect "java"
> import org.optaplanner.core.api.score.buildin.simple.SimpleScoreHolder;
> import org.optaplanner.core.impl.testdata.domain.TestdataValue;
> import org.optaplanner.core.impl.testdata.domain.TestdataEntity;
> global SimpleScoreHolder scoreHolder;
> // ############################################################################
> // Constraints
> // ############################################################################
> rule "Conflict"
> when
> TestdataEntity(value != null, $leftValue : value)
> TestdataEntity(value == $leftValue)
> then
> scoreHolder.addConstraintMatch(kcontext, -1);
> end
> {code}
> Not sure where the Object constructor reference comes from... This might be a JDK 9 upstream issue.
> Note: don't build drools with OpenJDK9 as that will fail sooner :)
> [1] https://github.com/droolsjbpm/optaplanner/blob/master/optaplanner-core/sr...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months