September 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12477) CommandDispatcher commands cannot read application jndi namespace

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-12477?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-12477: -------------------------------- Description: A command containing the following code: {noformat} public class MyCommand implements Command<Void, Void> { public Void execute(Void context) throws Exception { new InitialContext().lookup("java:comp/env/existing-resource"); } } {noformat} currently throws a NameNotFoundException, even though the same JNDI lookup succeeds on the caller that invoked the command. A command executed with the command dispatcher should be able to perform JNDI lookup from the local application namespace. In fact, the following application callbacks from the clustering API are unable to read from the application's JNDI namespace: * CommandDispatcher command execution * CommandDispatcherFactory cluster membership listener * Cache topology membership listener * Registry listener * ServiceProviderRegistry listener * Singleton election policy and listener > CommandDispatcher commands cannot read application jndi namespace > ----------------------------------------------------------------- > > Key: WFLY-12477 > URL: https://issues.jboss.org/browse/WFLY-12477 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 17.0.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > A command containing the following code: > {noformat} > public class MyCommand implements Command<Void, Void> { > public Void execute(Void context) throws Exception { > new InitialContext().lookup("java:comp/env/existing-resource"); > } > } > {noformat} > currently throws a NameNotFoundException, even though the same JNDI lookup succeeds on the caller that invoked the command. > A command executed with the command dispatcher should be able to perform JNDI lookup from the local application namespace. > In fact, the following application callbacks from the clustering API are unable to read from the application's JNDI namespace: > * CommandDispatcher command execution > * CommandDispatcherFactory cluster membership listener > * Cache topology membership listener > * Registry listener > * ServiceProviderRegistry listener > * Singleton election policy and listener -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6008) CommandDispatcher commands execute using wrong TCCL

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-6008?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-6008: ------------------------------- Description: A command containing the following code: {noformat} public class MyCommand implements Command<Void, Void> { public Void execute(Void context) throws Exception { Thread.currentThread().getClassLoader().loadClass(this.getClass().getName()); } } {noformat} currently throws a ClassNotFoundException. A command executed with the command dispatcher should be able to load application classes using the TCCL. In fact, the following application callbacks from the clustering API all use the wrong TCCL: * CommandDispatcher command execution * CommandDispatcherFactory cluster membership listener * Cache topology membership listener * Registry listener * ServiceProviderRegistry listener was: A command containing the following code: public class MyCommand implements Command<Void, Void> { public Void execute(Void context) throws Exception { Thread.currentThread().getClassLoader().loadClass(this.getClass().getName()); } } currently throws a ClassNotFoundException. A command executed with the command dispatcher should be able to load application classes using the TCCL. In fact, the following application callbacks from the clustering API all use the wrong TCCL: * CommandDispatcher command execution * CommandDispatcherFactory cluster membership listener * Cache topology membership listener * Registry listener * ServiceProviderRegistry listener > CommandDispatcher commands execute using wrong TCCL > --------------------------------------------------- > > Key: WFLY-6008 > URL: https://issues.jboss.org/browse/WFLY-6008 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR5 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > A command containing the following code: > {noformat} > public class MyCommand implements Command<Void, Void> { > public Void execute(Void context) throws Exception { > Thread.currentThread().getClassLoader().loadClass(this.getClass().getName()); > } > } > {noformat} > currently throws a ClassNotFoundException. > A command executed with the command dispatcher should be able to load application classes using the TCCL. > In fact, the following application callbacks from the clustering API all use the wrong TCCL: > * CommandDispatcher command execution > * CommandDispatcherFactory cluster membership listener > * Cache topology membership listener > * Registry listener > * ServiceProviderRegistry listener -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12477) CommandDispatcher commands cannot read application jndi namespace

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-12477: ----------------------------------- Summary: CommandDispatcher commands cannot read application jndi namespace Key: WFLY-12477 URL: https://issues.jboss.org/browse/WFLY-12477 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 17.0.1.Final Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4623) Intermittent failures in IdentityOperationsTestCase

by Ashley Abdel-Sayed (Jira)

[ https://issues.jboss.org/browse/WFCORE-4623?page=com.atlassian.jira.plugi... ] Ashley Abdel-Sayed commented on WFCORE-4623: -------------------------------------------- [~brian.stansberry] Thanks for this information! Do you have any suggestions for how to go about debugging this further? > Intermittent failures in IdentityOperationsTestCase > --------------------------------------------------- > > Key: WFCORE-4623 > URL: https://issues.jboss.org/browse/WFCORE-4623 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Brian Stansberry > Assignee: Ashley Abdel-Sayed > Priority: Major > Attachments: WFCORE-4623_hang.txt > > > IdentityOperationsTestCase fails intermittently, producing a set of 21 failures. When this happens the entire job seems to time out. > https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&bui... > The problem seems to involve a server not being able to reach MSC stability during boot and then a lot of problems trying to roll back the boot op. The latter are kind of noise, i.e. the stack trace bit in the snippet below. The key thing is the failure to get MSC stability. > {code} > 17:11:15,658 INFO (main) [org.wildfly.security] <Version.java:55> ELY00001: WildFly Elytron version 1.10.0.CR5 > 17:11:15,878 INFO (main) [org.jboss.msc] <ServiceContainerImpl.java:90> JBoss MSC version 1.4.8.Final > 17:11:15,893 INFO (main) [org.jboss.threads] <Version.java:52> JBoss Threads version 2.3.3.Final > 17:11:16,027 TRACE (main) [org.wildfly.security] <SecurityDomain.java:1056> Building security domain with defaultRealmName Empty. > 17:11:16,037 TRACE (main) [org.wildfly.security] <SecurityDomain.java:708> Role mapping: principal [anonymous] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [] > 17:11:16,312 TRACE (MSC service thread 1-2) [org.wildfly.extension.elytron] <ProviderDefinitions.java:238> Loaded providers [WildFlyElytron version 1.0] > 17:16:16,313 ERROR (Controller Boot Thread) [org.jboss.as.controller.management-operation] <OperationContextImpl.java:489> WFLYCTL0348: Timeout after [300] seconds waiting for service container stability. Operation will roll back. Step that first updated the service container was 'add' at address '[("path" => "jboss.server.data.dir")]' > 17:16:21,322 ERROR (Controller Boot Thread) [org.jboss.as.controller.management-operation] <AbstractOperationContext.java:1525> WFLYCTL0190: Step handler org.jboss.as.controller.AbstractAddStepHandler$1@b0b65f for operation add at address [ > ("subsystem" => "elytron"), > ("filesystem-realm" => "FileSystemRealm") > ] failed handling operation rollback -- java.util.concurrent.TimeoutException: java.util.concurrent.TimeoutException > at org.jboss.as.controller.OperationContextImpl.waitForRemovals(OperationContextImpl.java:523) > at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1518) > at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1472) > at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1455) > at org.jboss.as.controller.AbstractOperationContext$Step.access$400(AbstractOperationContext.java:1319) > at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:876) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1413) > at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:495) > {code} -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12471) Upgrade Narayana to 5.9.8.Final

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/WFLY-12471?page=com.atlassian.jira.plugin... ] Thomas Jenkinson updated WFLY-12471: ------------------------------------ Description: https://issues.jboss.org/projects/JBTM/versions/12342709 > Upgrade Narayana to 5.9.8.Final > ------------------------------- > > Key: WFLY-12471 > URL: https://issues.jboss.org/browse/WFLY-12471 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Reporter: Thomas Jenkinson > Assignee: Thomas Jenkinson > Priority: Major > > https://issues.jboss.org/projects/JBTM/versions/12342709 -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6008) CommandDispatcher commands execute using wrong TCCL

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-6008?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-6008: ------------------------------- Description: A command containing the following code: public class MyCommand implements Command<Void, Void> { public Void execute(Void context) throws Exception { Thread.currentThread().getClassLoader().loadClass(this.getClass().getName()); } } currently throws a ClassNotFoundException. A command executed with the command dispatcher should be able to load application classes using the TCCL. In fact, the following application callbacks from the clustering API all use the wrong TCCL: * CommandDispatcher command execution * CommandDispatcherFactory cluster membership listener * Cache topology membership listener * Registry listener * ServiceProviderRegistry listener was: The following callbacks use the org.wildfly.clustering.server classloader in : * CommandDispatcher command execution * CommandDispatcherFactory cluster membership listener * Cache topology membership listener * Registry listener * ServiceProviderRegistry listener > CommandDispatcher commands execute using wrong TCCL > --------------------------------------------------- > > Key: WFLY-6008 > URL: https://issues.jboss.org/browse/WFLY-6008 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR5 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > A command containing the following code: > public class MyCommand implements Command<Void, Void> { > public Void execute(Void context) throws Exception { > Thread.currentThread().getClassLoader().loadClass(this.getClass().getName()); > } > } > currently throws a ClassNotFoundException. > A command executed with the command dispatcher should be able to load application classes using the TCCL. > In fact, the following application callbacks from the clustering API all use the wrong TCCL: > * CommandDispatcher command execution > * CommandDispatcherFactory cluster membership listener > * Cache topology membership listener > * Registry listener > * ServiceProviderRegistry listener -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6008) CommandDispatcher commands execute using wrong TCCL

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-6008?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-6008: ------------------------------- Summary: CommandDispatcher commands execute using wrong TCCL (was: Clustering API callbacks/commands use wrong TCCL) > CommandDispatcher commands execute using wrong TCCL > --------------------------------------------------- > > Key: WFLY-6008 > URL: https://issues.jboss.org/browse/WFLY-6008 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR5 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > The following callbacks use the org.wildfly.clustering.server classloader in : > * CommandDispatcher command execution > * CommandDispatcherFactory cluster membership listener > * Cache topology membership listener > * Registry listener > * ServiceProviderRegistry listener -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6008) Clustering API callbacks/commands use wrong TCCL

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-6008?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-6008: ------------------------------- Description: The following callbacks use the org.wildfly.clustering.server classloader in : * CommandDispatcher command execution * CommandDispatcherFactory cluster membership listener * Cache topology membership listener * Registry listener * ServiceProviderRegistry listener was: The following callbacks leak the org.wildfly.clustering.server classloader to applications: * CommandDispatcher command execution * CommandDispatcherFactory cluster membership listener * Cache topology membership listener * Registry listener * ServiceProviderRegistry listener > Clustering API callbacks/commands use wrong TCCL > ------------------------------------------------ > > Key: WFLY-6008 > URL: https://issues.jboss.org/browse/WFLY-6008 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR5 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > The following callbacks use the org.wildfly.clustering.server classloader in : > * CommandDispatcher command execution > * CommandDispatcherFactory cluster membership listener > * Cache topology membership listener > * Registry listener > * ServiceProviderRegistry listener -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6008) Clustering API callbacks/commands use wrong TCCL

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-6008?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-6008: ------------------------------- Summary: Clustering API callbacks/commands use wrong TCCL (was: Clustering API leaks its classloader to applications) > Clustering API callbacks/commands use wrong TCCL > ------------------------------------------------ > > Key: WFLY-6008 > URL: https://issues.jboss.org/browse/WFLY-6008 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR5 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > The following callbacks leak the org.wildfly.clustering.server classloader to applications: > * CommandDispatcher command execution > * CommandDispatcherFactory cluster membership listener > * Cache topology membership listener > * Registry listener > * ServiceProviderRegistry listener -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4502) Fix ClientProducerDemo misconfiguration

by Daniele Zonca (Jira)

Daniele Zonca created DROOLS-4502: ------------------------------------- Summary: Fix ClientProducerDemo misconfiguration Key: DROOLS-4502 URL: https://issues.jboss.org/browse/DROOLS-4502 Project: Drools Issue Type: Bug Reporter: Daniele Zonca Assignee: Massimiliano Dessi -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 3 months

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 2019