[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
[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
[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
[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
[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
[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
[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