September 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9406) [WildFly 11] Update ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)

by Tibor Digana (JIRA)

[ https://issues.jboss.org/browse/WFLY-9406?page=com.atlassian.jira.plugin.... ] Tibor Digana updated WFLY-9406: ------------------------------- Description: Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaoCo uses ASM 5.2. The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. Please upgrade it in POM: https://github.com/wildfly/wildfly/blob/master/pom.xml was: Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaoCo uses ASM 5.2. The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{ org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. Please upgrade it in POM: https://github.com/wildfly/wildfly/blob/master/pom.xml > [WildFly 11] Update ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1) > ----------------------------------------------------------------------------------------- > > Key: WFLY-9406 > URL: https://issues.jboss.org/browse/WFLY-9406 > Project: WildFly > Issue Type: Component Upgrade > Components: CDI / Weld, Class Loading > Affects Versions: 11.0.0.CR1 > Reporter: Tibor Digana > Assignee: Martin Kouba > Priority: Critical > Fix For: 11.0.0.Final > > > Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 > Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaoCo uses ASM 5.2. > The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. > Please upgrade it in POM: > https://github.com/wildfly/wildfly/blob/master/pom.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-9406) [WildFly 11] Update ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)

by Tibor Digana (JIRA)

Tibor Digana created WFLY-9406: ---------------------------------- Summary: [WildFly 11] Update ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1) Key: WFLY-9406 URL: https://issues.jboss.org/browse/WFLY-9406 Project: WildFly Issue Type: Component Upgrade Components: CDI / Weld, Class Loading Affects Versions: 11.0.0.CR1 Reporter: Tibor Digana Assignee: Martin Kouba Priority: Critical Fix For: 11.0.0.Final Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaoCo uses ASM 5.2. The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{ org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. Please upgrade it in POM: https://github.com/wildfly/wildfly/blob/master/pom.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-3322) Invalid socket-binding config in remoting connector resource does not lead to model integrity failure

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3322: ---------------------------------------- Summary: Invalid socket-binding config in remoting connector resource does not lead to model integrity failure Key: WFCORE-3322 URL: https://issues.jboss.org/browse/WFCORE-3322 Project: WildFly Core Issue Type: Bug Components: Remoting Reporter: Brian Stansberry Assignee: Brian Stansberry A remoting connector with a socket-binding attribute pointing to a non-existing s-b does not fail with a capability validation failure: {code} [standalone@localhost:9990 /] /subsystem=remoting/connector=remoting-connector:add(security-realm=ApplicationRealm,socket-binding=remoting) { "outcome" => "failed", "failure-description" => { "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.network.socket-binding.remoting"], "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.remoting.server.remoting-connector is missing [org.wildfly.network.socket-binding.remoting]"] }, "rolled-back" => true } {code} As in all such cases of missing cap validation, that means it doesn't fail at all in admin-only: {code} [standalone@localhost:9990 /] reload --admin-only=true [standalone@localhost:9990 /] /subsystem=remoting/connector=remoting-connector:add(security-realm=ApplicationRealm,socket-binding=remoting) {"outcome" => "success"} {code} Problem is ConnectorAdd isn't passing its attributes into the superclass, which means the superclass' recording of capability requirements isn't done. I'll check for other occurrences of this pattern in the subsystem. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-9405) NPE when trying to recursively remove the EJB subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9405?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-9405: ----------------------------------- Workaround Description: Put the server in admin-only mode before removing the subsystem. {code} [standalone@localhost:9990 /] reload --admin-only=true [standalone@localhost:9990 /] /subsystem=ejb3:remove {"outcome" => "success"} {code} Putting the server in admin-only before doing this kind of surgery is probably a good idea anyway. was: Put the server in admin-only mode before removing the subsystem. {code} [standalone@localhost:9990 /] reload --admin-only=true [standalone@localhost:9990 /] /subsystem=ejb3:remove {"outcome" => "success"} {code} > NPE when trying to recursively remove the EJB subsystem > ------------------------------------------------------- > > Key: WFLY-9405 > URL: https://issues.jboss.org/browse/WFLY-9405 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.CR1 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > This fails: > {code} > [standalone@localhost:9990 /] /subsystem=ejb3:remove > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException", > "rolled-back" => true > } > {code} > with this in the server log: > {code} > 15:53:42,572 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("remove") failed - address: ([ > ("subsystem" => "ejb3"), > ("service" => "remote"), > ("channel-creation-options" => "MAX_OUTBOUND_MESSAGES") > ]): java.lang.NullPointerException > at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:894) > at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:884) > at org.jboss.as.controller.RestartParentResourceHandlerBase.getModel(RestartParentResourceHandlerBase.java:216) > at org.jboss.as.controller.RestartParentResourceHandlerBase.access$000(RestartParentResourceHandlerBase.java:39) > at org.jboss.as.controller.RestartParentResourceHandlerBase$1.execute(RestartParentResourceHandlerBase.java:66) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:980) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418) > ... > {code} > I believe a post-boot add of this resource would fail as well. > Problem is ChannelCreationOptionRemove and ChannelCreationOptionAdd in RemoteConnectorChannelCreationOptionResource use an incorrect parentKeyName. These handlers extend RestartParentResourceHandlerBase but are passing the *value* of the parent element as "parentKeyName" instead of its *key*; i.e. "remote" instead of "service". > Even though this code has been like this since 2012, this is somewhat a regression since before the current version our standard configs did not include resources of this type. So users could hit this in previous releases but now they are more likely to. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-9405) NPE when trying to recursively remove the EJB subsystem

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-9405: -------------------------------------- Summary: NPE when trying to recursively remove the EJB subsystem Key: WFLY-9405 URL: https://issues.jboss.org/browse/WFLY-9405 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 11.0.0.CR1 Reporter: Brian Stansberry Assignee: Brian Stansberry This fails: {code} [standalone@localhost:9990 /] /subsystem=ejb3:remove { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException", "rolled-back" => true } {code} with this in the server log: {code} 15:53:42,572 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("remove") failed - address: ([ ("subsystem" => "ejb3"), ("service" => "remote"), ("channel-creation-options" => "MAX_OUTBOUND_MESSAGES") ]): java.lang.NullPointerException at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:894) at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:884) at org.jboss.as.controller.RestartParentResourceHandlerBase.getModel(RestartParentResourceHandlerBase.java:216) at org.jboss.as.controller.RestartParentResourceHandlerBase.access$000(RestartParentResourceHandlerBase.java:39) at org.jboss.as.controller.RestartParentResourceHandlerBase$1.execute(RestartParentResourceHandlerBase.java:66) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:980) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418) ... {code} I believe a post-boot add of this resource would fail as well. Problem is ChannelCreationOptionRemove and ChannelCreationOptionAdd in RemoteConnectorChannelCreationOptionResource use an incorrect parentKeyName. These handlers extend RestartParentResourceHandlerBase but are passing the *value* of the parent element as "parentKeyName" instead of its *key*; i.e. "remote" instead of "service". Even though this code has been like this since 2012, this is somewhat a regression since before the current version our standard configs did not include resources of this type. So users could hit this in previous releases but now they are more likely to. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-9404) [GSS](7.2.0) Unable to deploy clustered ejb in a mixed domain.

by Brad Maxwell (JIRA)

Brad Maxwell created WFLY-9404: ---------------------------------- Summary: [GSS](7.2.0) Unable to deploy clustered ejb in a mixed domain. Key: WFLY-9404 URL: https://issues.jboss.org/browse/WFLY-9404 Project: WildFly Issue Type: Bug Components: Clustering, EJB Affects Versions: 11.0.0.CR1 Reporter: Brad Maxwell Assignee: Paul Ferraro Attachments: Clusterejb-0.0.1.jar, domain_EAP7.xml, host_EAP7.xml, host_slave_EAP6.xml Using a ha profile in a mixed domain( i.e EAP 7 as a domain controler and EAP 6.3 as a slave) it does not seem possible to deploy ejb successfully. While deploying a simple @clustered ejb on EAP 6.3 server below exception was thrown. This issue is easily replicated. {code:java} 19:12:11,886 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-16) JNDI bindings for session bean named CounterBean in deployment unit deployment "Clusterejb-0.0.1.jar" are as follows: java:global/Clusterejb-0.0.1/CounterBean!com.test.Counter java:app/Clusterejb-0.0.1/CounterBean!com.test.Counter java:module/CounterBean!com.test.Counter java:jboss/exported/Clusterejb-0.0.1/CounterBean!com.test.Counter java:global/Clusterejb-0.0.1/CounterBean java:app/Clusterejb-0.0.1/CounterBean java:module/CounterBean 19:12:12,089 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "Clusterejb-0.0.1.jar" (runtime-name : "Clusterejb-0.0.1.jar") 19:12:12,090 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report JBAS014775: New missing/unsatisfied dependencies: service jboss.ejb.cache.cluster.simple (missing) dependents: [service jboss.ejb.cache.cluster] 19:12:12,093 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss EAP 6.3.0.GA (AS 7.4.0.Final-redhat-19) started (with errors) in 2654ms - Started 185 of 293 services (14 services failed or missing dependencies, 117 services are lazy, passive or on-demand) {code} I have attached the configuration files for both EAP 7 and EAP 6. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-9403) Unable to deploy clustered ejb in a mixed domain.

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-9403?page=com.atlassian.jira.plugin.... ] Brad Maxwell moved JBEAP-13293 to WFLY-9403: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-9403 (was: JBEAP-13293) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering EJB (was: Clustering) (was: EJB) Affects Version/s: 11.0.0.CR1 (was: 7.0.7.GA) > Unable to deploy clustered ejb in a mixed domain. > ------------------------------------------------- > > Key: WFLY-9403 > URL: https://issues.jboss.org/browse/WFLY-9403 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 11.0.0.CR1 > Reporter: Brad Maxwell > Assignee: Paul Ferraro > Attachments: Clusterejb-0.0.1.jar, domain_EAP7.xml, host_EAP7.xml, host_slave_EAP6.xml > > > Using a ha profile in a mixed domain( i.e EAP 7 as a domain controler and EAP 6.3 as a slave) it does not seem possible to deploy ejb successfully. > While deploying a simple @clustered ejb on EAP 6.3 server below exception was thrown. This issue is easily replicated. > {code:java} > 19:12:11,886 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-16) JNDI bindings for session bean named CounterBean in deployment unit deployment "Clusterejb-0.0.1.jar" are as follows: > java:global/Clusterejb-0.0.1/CounterBean!com.test.Counter > java:app/Clusterejb-0.0.1/CounterBean!com.test.Counter > java:module/CounterBean!com.test.Counter > java:jboss/exported/Clusterejb-0.0.1/CounterBean!com.test.Counter > java:global/Clusterejb-0.0.1/CounterBean > java:app/Clusterejb-0.0.1/CounterBean > java:module/CounterBean > 19:12:12,089 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "Clusterejb-0.0.1.jar" (runtime-name : "Clusterejb-0.0.1.jar") > 19:12:12,090 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.ejb.cache.cluster.simple (missing) dependents: [service jboss.ejb.cache.cluster] > 19:12:12,093 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss EAP 6.3.0.GA (AS 7.4.0.Final-redhat-19) started (with errors) in 2654ms - Started 185 of 293 services (14 services failed or missing dependencies, 117 services are lazy, passive or on-demand) > {code} > I have attached the configuration files for both EAP 7 and EAP 6. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2951) Add JSON formatter resources to the logging subsystem

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2951?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-2951: --------------------------------------- Adding a logstash formatter would likely only be for convenience. Really it's just a {{json-formatter}} with the {{timestamp}} key replaced with {{@timestamp}} and a {{@version : 1}} key/value pair added to the output. This would be very easy to do with the {{json-formatter}} itself. In fact dropping the {{org.jboss.logmanager.formatters.LogstashFormatter}} is being considered. > Add JSON formatter resources to the logging subsystem > ----------------------------------------------------- > > Key: WFCORE-2951 > URL: https://issues.jboss.org/browse/WFCORE-2951 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 4.0.0.Beta1 > > > The logging subsystem should include resources for a {{json-formatter}} -and probably a {{logstash-formatter}}. The {{logstash-formatter}} is likely just an extension of the {{json-formatter}} with some predefined attributes that logstash requires-. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2951) Add JSON formatter resources to the logging subsystem

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2951?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-2951: ---------------------------------- Description: The logging subsystem should include resources for a {{json-formatter}} -and probably a {{logstash-formatter}}. The {{logstash-formatter}} is likely just an extension of the {{json-formatter}} with some predefined attributes that logstash requires-. (was: The logging subsystem should include resources for a {{json-formatter}} and probably a {{logstash-formatter}}. The {{logstash-formatter}} is likely just an extension of the {{json-formatter}} with some predefined attributes that logstash requires.) > Add JSON formatter resources to the logging subsystem > ----------------------------------------------------- > > Key: WFCORE-2951 > URL: https://issues.jboss.org/browse/WFCORE-2951 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 4.0.0.Beta1 > > > The logging subsystem should include resources for a {{json-formatter}} -and probably a {{logstash-formatter}}. The {{logstash-formatter}} is likely just an extension of the {{json-formatter}} with some predefined attributes that logstash requires-. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2951) Add JSON formatter resources to the logging subsystem

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2951?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-2951: ---------------------------------- Summary: Add JSON formatter resources to the logging subsystem (was: Add JSON and Logstash formatter resources to the logging subsystem) > Add JSON formatter resources to the logging subsystem > ----------------------------------------------------- > > Key: WFCORE-2951 > URL: https://issues.jboss.org/browse/WFCORE-2951 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 4.0.0.Beta1 > > > The logging subsystem should include resources for a {{json-formatter}} and probably a {{logstash-formatter}}. The {{logstash-formatter}} is likely just an extension of the {{json-formatter}} with some predefined attributes that logstash requires. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2017