[JBoss JIRA] (ELY-872) JBoss Modules is not an optional dependency
by Jeff Mesnil (JIRA)
Jeff Mesnil created ELY-872:
-------------------------------
Summary: JBoss Modules is not an optional dependency
Key: ELY-872
URL: https://issues.jboss.org/browse/ELY-872
Project: WildFly Elytron
Issue Type: Bug
Components: Authentication Client
Affects Versions: 1.1.0.Beta19
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
WFLY-7864 is an issue hit by the helloworld-jms quickstart example. It is a standalone Java app using plain classpath (JBoss Modules is not present).
I have found an issue in JBoss Remoting that was causing an issue when JBoss Modules was not present (REM3-244). After patching JBoss Remoting, I see a similar issue with Elytron:
{code}
[WARNING]
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ExceptionInInitializerError
at org.wildfly.security.auth.client.AuthenticationContext.lambda$static$0(AuthenticationContext.java:49)
at org.wildfly.common.context.ContextManager.getPrivileged(ContextManager.java:205)
at org.wildfly.security.auth.client.AuthenticationContext.captureCurrent(AuthenticationContext.java:81)
at org.jboss.remoting3.EndpointImpl.construct(EndpointImpl.java:211)
at org.jboss.remoting3.EndpointBuilder.build(EndpointBuilder.java:117)
at org.jboss.remoting3.RemotingXmlParser.parseEndpoint(RemotingXmlParser.java:52)
at org.jboss.remoting3.ConfigurationEndpointSupplier.lambda$static$0(ConfigurationEndpointSupplier.java:51)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.remoting3.ConfigurationEndpointSupplier.<clinit>(ConfigurationEndpointSupplier.java:48)
at org.wildfly.common.context.ContextManager.setGlobalDefaultSupplierIfNotSet(ContextManager.java:108)
at org.jboss.remoting3.Endpoint.lambda$static$0(Endpoint.java:58)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.remoting3.Endpoint.<clinit>(Endpoint.java:56)
at org.wildfly.naming.client.remote.RemoteNamingProviderFactory.supportsUriScheme(RemoteNamingProviderFactory.java:70)
at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:318)
at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:123)
at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:113)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.jboss.as.quickstarts.jms.HelloWorldJMSClient.main(HelloWorldJMSClient.java:62)
... 6 more
Caused by: org.wildfly.security.auth.client.InvalidAuthenticationConfigurationException: java.lang.NoClassDefFoundError: org/jboss/modules/ModuleClassLoader
at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:44)
at java.security.AccessController.doPrivileged(Native Method)
at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.<clinit>(DefaultAuthenticationContextProvider.java:36)
... 25 more
Caused by: java.lang.NoClassDefFoundError: org/jboss/modules/ModuleClassLoader
at org.wildfly.security.auth.client.DefaultAuthenticationContextProvider.lambda$static$0(DefaultAuthenticationContextProvider.java:42)
... 27 more
Caused by: java.lang.ClassNotFoundException: org.jboss.modules.ModuleClassLoader
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
{code}
According to Elytron's POM, JBoss Modules should be be optional and a standalone Java app should not require it to be able to use Elytron's client authentication.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFCORE-1752) The deployment-overlay command fails to redeploy affected deployments
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1752?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1752:
----------------------------------------------
[~brian.stansberry],
moving to the server side, I guess that is a question for [~swd847].
> The deployment-overlay command fails to redeploy affected deployments
> ---------------------------------------------------------------------
>
> Key: WFCORE-1752
> URL: https://issues.jboss.org/browse/WFCORE-1752
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha5
> Reporter: ehsavoie Hugonnet
> Assignee: Jean-Francois Denise
>
> The deployment-overlay command fails to redeploy affected deployments if the runtime-name isn't the same as the deployment name. Since affected deployment to be redeployed should be running the couple runtime-name + enabled == true should be used to define which deployments are affected instead of using the deployment name since the name used in overlay is the runtime-name
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (JGRP-2152) ASYM_ENCRYPT failure on Wildfly 10.1.0
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2152?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2152 at 1/13/17 3:10 AM:
---------------------------------------------------------
ASYM_ENCRYPT requires AUTH, can you retry with AUTH? See \[1\] in my original comment. Which version of JGroups did you use here? I see that Wildfly master uses 3.6.11 (?), which does NOT have the fix \[1\].
\[1\] https://issues.jboss.org/browse/JGRP-2131
was (Author: belaban):
ASYM_ENCRYPT requires AUTH, can you retry with AUTH? See \[1\] in my original comment.
> ASYM_ENCRYPT failure on Wildfly 10.1.0
> --------------------------------------
>
> Key: JGRP-2152
> URL: https://issues.jboss.org/browse/JGRP-2152
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Matt Wringe
> Assignee: Bela Ban
> Fix For: 4.0, 3.6.13
>
> Attachments: hawkular-metrics-1.log, hawkular-metrics-2.log, org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output.txt, standalone.xml
>
>
> Using ASYM_ENCRYPT on Wildfly 10.1.0 seems to be broken.
> I am using the parameters for ASYM_ENCRYPT specified in http://www.jgroups.org/manual/index.html#Security
> Note: running with SYM_ENCRYPT doesn't cause any issues and it works fine with my setup. Its only ASYM_ENCRYPT which is currently failing.
> Note: running this on EAP fails in a similar manner.
> Eg:
> <protocol type="ASYM_ENCRYPT">
> <property name="encrypt_entire_message">true</property>
> <property name="sym_keylength">128</property>
> <property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
> <property name="asym_keylength">512</property>
> <property name="asym_algorithm">RSA</property>
> </protocol>
> If I run a single instance, then I don't see any problems appear in the logs. Its when I start a second instance that I start to see errors about unrecognised ciphers and timeouts.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7880) Wildfly 10 admin console does not show log files
by Davy Steegen (JIRA)
[ https://issues.jboss.org/browse/WFLY-7880?page=com.atlassian.jira.plugin.... ]
Davy Steegen commented on WFLY-7880:
------------------------------------
Thank you for pointing me to this part of the documentation. I must have missed it while investigating the problem.
We'll make sure that these File Handlers are configured for the corresponding log files.
> Wildfly 10 admin console does not show log files
> ------------------------------------------------
>
> Key: WFLY-7880
> URL: https://issues.jboss.org/browse/WFLY-7880
> Project: WildFly
> Issue Type: Bug
> Components: Logging
> Affects Versions: 10.1.0.Final
> Reporter: Davy Steegen
> Assignee: James Perkins
> Attachments: log4j.properties
>
>
> When using "per deployment logging", the WildFly 10 admin console does not show the log files that I configured in my log4j configuration (only those that are managed via the WildFly itself).
> You can find an example log4j configuration in the attachments. It contains a File appender that logs in a file called client.log (relative to the WildFly log directory).
> The workaround is to create a Logging Handler of type File in the admin console per log file I want to monitor in the admin console. However, in our case the WildFly is managed by another team. We don't want to botter them each time we add a new log file.
> Am I missing something or does this work as designed ?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (JGRP-2152) ASYM_ENCRYPT failure on Wildfly 10.1.0
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2152?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2152:
--------------------------------
ASYM_ENCRYPT requires AUTH, can you retry with AUTH? See \[1\] in my original comment.
> ASYM_ENCRYPT failure on Wildfly 10.1.0
> --------------------------------------
>
> Key: JGRP-2152
> URL: https://issues.jboss.org/browse/JGRP-2152
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Matt Wringe
> Assignee: Bela Ban
> Fix For: 4.0, 3.6.13
>
> Attachments: hawkular-metrics-1.log, hawkular-metrics-2.log, org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output.txt, standalone.xml
>
>
> Using ASYM_ENCRYPT on Wildfly 10.1.0 seems to be broken.
> I am using the parameters for ASYM_ENCRYPT specified in http://www.jgroups.org/manual/index.html#Security
> Note: running with SYM_ENCRYPT doesn't cause any issues and it works fine with my setup. Its only ASYM_ENCRYPT which is currently failing.
> Note: running this on EAP fails in a similar manner.
> Eg:
> <protocol type="ASYM_ENCRYPT">
> <property name="encrypt_entire_message">true</property>
> <property name="sym_keylength">128</property>
> <property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
> <property name="asym_keylength">512</property>
> <property name="asym_algorithm">RSA</property>
> </protocol>
> If I run a single instance, then I don't see any problems appear in the logs. Its when I start a second instance that I start to see errors about unrecognised ciphers and timeouts.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFCORE-2171) StackOverflowError after repeated management write ops
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2171?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2171:
-------------------------------------
Description:
I wrote an integration test that allows you to set a system prop and based on the value X it repeatedly calls full-replace-deployment X times (see https://github.com/wildfly/wildfly-core/pull/2062). When I try and run it 30K times I get:
2017-01-09 22:28:40,431 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]): java.lang.StackOverflowError
at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030)
at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030)
at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030)
.... repeat over and over
I think this is due to BasicResource.clone()'s handling of orderedChildResources. It takes the internal set, wraps it in Collections.unmodifiableSet and passes it in to the clone, which in turn will do the same thing if cloned. So for each management write op, the same underlying set gets wrapped in another layer. Hence the overflow of size calls.
was:
I wrote an integration test that allows you to set a system prop and repeatedly call full-replace-deployment (see https://github.com/wildfly/wildfly-core/pull/2062). When I try and run it 30K times I get:
2017-01-09 22:28:40,431 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]): java.lang.StackOverflowError
at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030)
at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030)
at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030)
.... repeat over and over
I think this is due to BasicResource.clone()'s handling of orderedChildResources. It takes the internal set, wraps it in Collections.unmodifiableSet and passes it in to the clone, which in turn will do the same thing if cloned. So for each management write op, the same underlying set gets wrapped in another layer. Hence the overflow of size calls.
> StackOverflowError after repeated management write ops
> ------------------------------------------------------
>
> Key: WFCORE-2171
> URL: https://issues.jboss.org/browse/WFCORE-2171
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha18
>
>
> I wrote an integration test that allows you to set a system prop and based on the value X it repeatedly calls full-replace-deployment X times (see https://github.com/wildfly/wildfly-core/pull/2062). When I try and run it 30K times I get:
> 2017-01-09 22:28:40,431 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]): java.lang.StackOverflowError
> at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030)
> at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030)
> at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030)
> .... repeat over and over
> I think this is due to BasicResource.clone()'s handling of orderedChildResources. It takes the internal set, wraps it in Collections.unmodifiableSet and passes it in to the clone, which in turn will do the same thing if cloned. So for each management write op, the same underlying set gets wrapped in another layer. Hence the overflow of size calls.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFCORE-2171) StackOverflowError after repeated management write ops
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2171?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2171:
-------------------------------------
Description:
I wrote an integration test that allows you to set a system prop and repeatedly call full-replace-deployment (see https://github.com/wildfly/wildfly-core/pull/2062). When I try and run it 30K times I get:
2017-01-09 22:28:40,431 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]): java.lang.StackOverflowError
at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030)
at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030)
at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030)
.... repeat over and over
I think this is due to BasicResource.clone()'s handling of orderedChildResources. It takes the internal set, wraps it in Collections.unmodifiableSet and passes it in to the clone, which in turn will do the same thing if cloned. So for each management write op, the same underlying set gets wrapped in another layer. Hence the overflow of size calls.
was:
I wrote an integration test that allows you to set a system prop and repeatedly call full-replace-deployment (see https://github.com/wildfly/wildfly-core/pull/2062). When I try and run it 30K times I get:
2017-01-09 22:28:40,431 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]): java.lang.StackOverflowError
at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030)
at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030)
at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030)
I think this is due to BasicResource.clone()'s handling of orderedChildResources. It takes the internal set, wraps it in Collections.unmodifiableSet and passes it in to the clone, which in turn will do the same thing if cloned. So for each management write op, the same underlying set gets wrapped in another layer. Hence the overflow of size calls.
> StackOverflowError after repeated management write ops
> ------------------------------------------------------
>
> Key: WFCORE-2171
> URL: https://issues.jboss.org/browse/WFCORE-2171
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha18
>
>
> I wrote an integration test that allows you to set a system prop and repeatedly call full-replace-deployment (see https://github.com/wildfly/wildfly-core/pull/2062). When I try and run it 30K times I get:
> 2017-01-09 22:28:40,431 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]): java.lang.StackOverflowError
> at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030)
> at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030)
> at java.util.Collections$UnmodifiableCollection.size(Collections.java:1030)
> .... repeat over and over
> I think this is due to BasicResource.clone()'s handling of orderedChildResources. It takes the internal set, wraps it in Collections.unmodifiableSet and passes it in to the clone, which in turn will do the same thing if cloned. So for each management write op, the same underlying set gets wrapped in another layer. Hence the overflow of size calls.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7197) Allow configuration of an Elytron SSLContext in the IIOP subsystem
by Stefan Guilhen (JIRA)
[ https://issues.jboss.org/browse/WFLY-7197?page=com.atlassian.jira.plugin.... ]
Stefan Guilhen updated WFLY-7197:
---------------------------------
Parent: WFLY-6393
Issue Type: Sub-task (was: Feature Request)
> Allow configuration of an Elytron SSLContext in the IIOP subsystem
> ------------------------------------------------------------------
>
> Key: WFLY-7197
> URL: https://issues.jboss.org/browse/WFLY-7197
> Project: WildFly
> Issue Type: Sub-task
> Components: IIOP
> Reporter: Stefan Guilhen
> Assignee: Stefan Guilhen
> Labels: affects_elytron
>
> Currently the IIOP subsystem defines an attribute that references a JSSE security domain to obtain the key and trust managers used by the SSLSocketFactory to build an SSLContext instance.
> With Elytron we now have a new capability that exposes SSLContext instances and we should be able to use that in the IIOP subsystem. A new attribute must be added to allow for the specification of the Elytron SSLContext that should be used. The SSLSocketFactory will still support the old JSSE-based configuration but will be able to make use of Elytron's centralized SSL configuration to obtain an SSLContext.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (DROOLS-1405) Drools compiler throws NPE on DRL save when more than one rule extends same rule in the same package
by Gal Nitzan (JIRA)
Gal Nitzan created DROOLS-1405:
----------------------------------
Summary: Drools compiler throws NPE on DRL save when more than one rule extends same rule in the same package
Key: DROOLS-1405
URL: https://issues.jboss.org/browse/DROOLS-1405
Project: Drools
Issue Type: Bug
Affects Versions: 7.0.0.Beta5, 6.5.0.Final
Environment: Linux - CentOS 6.8
wildfly 10.0.1
kie 6.5.x and 7 snapshot
Reporter: Gal Nitzan
Assignee: Edson Tirelli
Hi,
I get the following error when saving a DRL file:
2017-01-12 23:16:39,677 INFO [org.guvnor.common.services.builder.ResourceChangeIncrementalBuilder] (EJB default - 10) Incremental build request being processed: default://master@opsc/health/src/main/resources/com/opsc/health/test2.drl (updated).
2017-01-12 23:16:39,730 ERROR [org.kie.workbench.common.services.backend.builder.Builder] (EJB default - 10) null: java.lang.NullPointerException
at java.util.LinkedList.addAll(LinkedList.java:408)
at java.util.LinkedList.addAll(LinkedList.java:387)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.sortRulesByDependency(KnowledgeBuilderImpl.java:1231)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:1086)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileAllRules(KnowledgeBuilderImpl.java:989)
at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildRules(CompositeKnowledgeBuilderImpl.java:264)
at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:122)
at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:105)
at org.drools.compiler.kie.builder.impl.KieBuilderSetImpl.buildChanges(KieBuilderSetImpl.java:142)
at org.drools.compiler.kie.builder.impl.KieBuilderSetImpl.build(KieBuilderSetImpl.java:94)
at org.kie.workbench.common.services.backend.builder.Builder.buildIncrementally(Builder.java:539)
at org.kie.workbench.common.services.backend.builder.Builder.addResource(Builder.java:383)
at org.kie.workbench.common.services.backend.builder.Builder.addResource(Builder.java:324)
at org.kie.workbench.common.services.backend.builder.Builder.updateResource(Builder.java:405)
at org.kie.workbench.common.services.backend.builder.BuildServiceImpl.lambda$updatePackageResource$1(BuildServiceImpl.java:320)
at org.kie.workbench.common.services.backend.builder.BuildServiceImpl.updatePackageResource(BuildServiceImpl.java:338)
at org.kie.workbench.common.services.backend.builder.BuildServiceImpl.updatePackageResource(BuildServiceImpl.java:319)
at org.kie.workbench.common.services.backend.builder.BuildServiceImpl$Proxy$_$$_WeldClientProxy.updatePackageResource(Unknown Source)
at org.guvnor.common.services.builder.ResourceChangeIncrementalBuilder$4.execute(ResourceChangeIncrementalBuilder.java:267)
at org.guvnor.common.services.builder.IncrementalBuilderExecutorManager.execute(IncrementalBuilderExecutorManager.java:77)
at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:313)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:237)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:82)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$2.runInvocation(AsyncFutureInterceptorFactory.java:104)
at org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:74)
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)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months