[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, 8 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, 8 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, 8 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, 8 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, 8 months
[JBoss JIRA] (ELY-1873) JaccDelegatingPolicy should allow non JACC modifications to pass through.
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1873?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1873:
----------------------------------
Description:
Errors such as the following can be seen within the application server: -
{noformat}
Caused by: java.lang.SecurityException: ELY03018: Cannot add permissions to a read-only permission collection
at org.wildfly.security.authz.jacc.JaccDelegatingPolicy$1.add(JaccDelegatingPolicy.java:127) [wildfly-elytron-jacc-1.10.0.CR6.jar:1.10.0.CR6]
at sun.rmi.server.LoaderHandler.getLoaderAccessControlContext(LoaderHandler.java:1005) [rt.jar:1.8.0_222]
at sun.rmi.server.LoaderHandler.lookupLoader(LoaderHandler.java:881) [rt.jar:1.8.0_222]
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:404) [rt.jar:1.8.0_222]
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:186) [rt.jar:1.8.0_222]
at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:637) [rt.jar:1.8.0_222]
at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:219) [rt.jar:1.8.0_222]
at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:152) [rt.jar:1.8.0_222]
at com.sun.corba.se.impl.util.JDKBridge.loadClassM(JDKBridge.java:189) [rt.jar:1.8.0_222]
at com.sun.corba.se.impl.util.JDKBridge.loadClass(JDKBridge.java:89) [rt.jar:1.8.0_222]
at com.sun.corba.se.impl.javax.rmi.CORBA.Util.loadClass(Util.java:605) [rt.jar:1.8.0_222]
at javax.rmi.CORBA.Util.loadClass(Util.java:259) [rt.jar:1.8.0_222]
at com.sun.corba.se.impl.presentation.rmi.StubFactoryFactoryDynamicBase.createStubFactory(StubFactoryFactoryDynamicBase.java:64) [rt.jar:1.8.0_222]
at org.wildfly.iiop.openjdk.rmi.DelegatingStubFactoryFactory.getStubFactoryImpl(DelegatingStubFactoryFactory.java:76)
at org.wildfly.iiop.openjdk.rmi.DelegatingStubFactoryFactory.access$000(DelegatingStubFactoryFactory.java:41)
at org.wildfly.iiop.openjdk.rmi.DelegatingStubFactoryFactory$1.run(DelegatingStubFactoryFactory.java:58)
at org.wildfly.iiop.openjdk.rmi.DelegatingStubFactoryFactory$1.run(DelegatingStubFactoryFactory.java:55)
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_222]
at org.wildfly.iiop.openjdk.rmi.DelegatingStubFactoryFactory.createStubFactory(DelegatingStubFactoryFactory.java:55)
at com.sun.corba.se.impl.util.Utility.loadStub(Utility.java:780) [rt.jar:1.8.0_222]
... 11 more
{noformat}
In this scenario the permission was RuntimePermission("java.lang.RuntimePermission" "createClassLoader") so should be related to the ProtectionDomain of the class loader and not the JACC permission collection.
> JaccDelegatingPolicy should allow non JACC modifications to pass through.
> -------------------------------------------------------------------------
>
> Key: ELY-1873
> URL: https://issues.jboss.org/browse/ELY-1873
> Project: WildFly Elytron
> Issue Type: Bug
> Components: EE
> Affects Versions: 1.10.0.Final
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 1.10.1.CR1
>
>
> Errors such as the following can be seen within the application server: -
> {noformat}
> Caused by: java.lang.SecurityException: ELY03018: Cannot add permissions to a read-only permission collection
> at org.wildfly.security.authz.jacc.JaccDelegatingPolicy$1.add(JaccDelegatingPolicy.java:127) [wildfly-elytron-jacc-1.10.0.CR6.jar:1.10.0.CR6]
> at sun.rmi.server.LoaderHandler.getLoaderAccessControlContext(LoaderHandler.java:1005) [rt.jar:1.8.0_222]
> at sun.rmi.server.LoaderHandler.lookupLoader(LoaderHandler.java:881) [rt.jar:1.8.0_222]
> at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:404) [rt.jar:1.8.0_222]
> at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:186) [rt.jar:1.8.0_222]
> at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:637) [rt.jar:1.8.0_222]
> at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:219) [rt.jar:1.8.0_222]
> at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:152) [rt.jar:1.8.0_222]
> at com.sun.corba.se.impl.util.JDKBridge.loadClassM(JDKBridge.java:189) [rt.jar:1.8.0_222]
> at com.sun.corba.se.impl.util.JDKBridge.loadClass(JDKBridge.java:89) [rt.jar:1.8.0_222]
> at com.sun.corba.se.impl.javax.rmi.CORBA.Util.loadClass(Util.java:605) [rt.jar:1.8.0_222]
> at javax.rmi.CORBA.Util.loadClass(Util.java:259) [rt.jar:1.8.0_222]
> at com.sun.corba.se.impl.presentation.rmi.StubFactoryFactoryDynamicBase.createStubFactory(StubFactoryFactoryDynamicBase.java:64) [rt.jar:1.8.0_222]
> at org.wildfly.iiop.openjdk.rmi.DelegatingStubFactoryFactory.getStubFactoryImpl(DelegatingStubFactoryFactory.java:76)
> at org.wildfly.iiop.openjdk.rmi.DelegatingStubFactoryFactory.access$000(DelegatingStubFactoryFactory.java:41)
> at org.wildfly.iiop.openjdk.rmi.DelegatingStubFactoryFactory$1.run(DelegatingStubFactoryFactory.java:58)
> at org.wildfly.iiop.openjdk.rmi.DelegatingStubFactoryFactory$1.run(DelegatingStubFactoryFactory.java:55)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_222]
> at org.wildfly.iiop.openjdk.rmi.DelegatingStubFactoryFactory.createStubFactory(DelegatingStubFactoryFactory.java:55)
> at com.sun.corba.se.impl.util.Utility.loadStub(Utility.java:780) [rt.jar:1.8.0_222]
> ... 11 more
> {noformat}
> In this scenario the permission was RuntimePermission("java.lang.RuntimePermission" "createClassLoader") so should be related to the ProtectionDomain of the class loader and not the JACC permission collection.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12476) Improve user experience of global directory
by Marek Kopecky (Jira)
[ https://issues.jboss.org/browse/WFLY-12476?page=com.atlassian.jira.plugin... ]
Marek Kopecky updated WFLY-12476:
---------------------------------
Priority: Major (was: Minor)
> Improve user experience of global directory
> -------------------------------------------
>
> Key: WFLY-12476
> URL: https://issues.jboss.org/browse/WFLY-12476
> Project: WildFly
> Issue Type: Feature Request
> Components: Class Loading
> Reporter: Tomas Terem
> Assignee: Yeray Borges
> Priority: Major
>
> Global directory was introduced in https://issues.jboss.org/browse/WFLY-1160. There are few user experience issues that are yet to be solved so I am creating this follow-up jira for them.
> Issues:
> 1. If some class throws an exception, is user informed which jar contains this class?
> Currently, no. This could be implemented.
> 2. What if global directory contains corrupted jar file? E.g. text file which was renamed to .jar
> Server logs contains information that zip file could not be opened. Cli only prints out that deployment is missing dependencies.
> This could be improved.
> 3. What if global directory contains one correct jar and one corrupted jar? Application only needs that correct jar to work.
> Crash during deployment. Cli says that deployment is missing dependencies.
> This could be improved.
> 4. Can user specify dependencies for their libraries? For example to use MP or Hibernate API?
> No.
> It would be good if something like this was possible:
> /subsystem=ee/global-directory=my-common-libs:add(path=lib, relative-to=jboss.home.dir, dependencies=[{name=org.hibernate.something,export=true,import=false}])
> 5. What should happen if jar contains class that has same name and package as some java ee class?
> Tried with custom javax.ws.rs.client.Client:
> org.jboss.resteasy.spi.UnhandledException: java.lang.LinkageError: loader constraint violation: loader (instance of org/jboss/modules/ModuleClassLoader) previously initiated loading for a different type with name "javax/ws/rs/client/Client"
> This could be improved - at least warning during deployment could be shown.
> 6. Global directory has following hierarchy:
> a/a.1.jar
> ---- A.class
> b/a.2.jar
> ---- A.class
> ---- B.class
> Class B uses A's feature that is only available in a.2.jar version of A.class.
> Fail during runtime when class B tries to access new feature of class A.
> Same as above - at least warning during deployment could be shown.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months