[JBoss JIRA] (WFLY-4784) @Transactional annotation on stereotype leads to error "ARJUNA016107: Expected an @Transactional annotation at class and/or method level"
by Alexander Morozov (JIRA)
[ https://issues.jboss.org/browse/WFLY-4784?page=com.atlassian.jira.plugin.... ]
Alexander Morozov updated WFLY-4784:
------------------------------------
Attachment: wildfly-jta-cdi.zip
> @Transactional annotation on stereotype leads to error "ARJUNA016107: Expected an @Transactional annotation at class and/or method level"
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4784
> URL: https://issues.jboss.org/browse/WFLY-4784
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Transactions
> Affects Versions: 8.2.0.Final, 9.0.0.CR1
> Environment: JDK 1.7u72 x64, Windows 8.1 Professional
> Reporter: Alexander Morozov
> Assignee: Stuart Douglas
> Priority: Critical
> Attachments: wildfly-jta-cdi.zip
>
>
> It is seems that CDI Transactional extesion doesn't support well @Transactional annotation on CDI stereotypes. JTA transaction is created by library interceptor, but in case of exception on component's side, _com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(...)_ method failed to locate @Transactional annotation on target component. It leads to exception like that
> {code}
> java.lang.RuntimeException: ARJUNA016107: Expected an @Transactional annotation at class and/or method level
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(TransactionalInterceptorBase.java:83)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.handleException(TransactionalInterceptorBase.java:118)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInCallerTx(TransactionalInterceptorBase.java:106)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorMandatory.intercept(TransactionalInterceptorMandatory.java:58)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74)
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84)
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72)
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56)
> at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79)
> at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68)
> at com.mycompany.wildfly.jta.cdi.UserEventDispatcher$Proxy$_$$_WeldSubclass.dispatch(Unknown Source)
> at com.mycompany.wildfly.jta.cdi.UserEventDispatcher$Proxy$_$$_WeldClientProxy.dispatch(Unknown Source)
> at com.mycompany.wildfly.jta.cdi.UserApplicationService.addUser(UserApplicationService.java:18)
> at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldSubclass.addUser$$super(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:49)
> at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:77)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:92)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74)
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84)
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72)
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56)
> at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79)
> at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68)
> at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldSubclass.addUser(Unknown Source)
> at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldClientProxy.addUser(Unknown Source)
> at com.mycompany.wildfly.jta.cdi.BootstrapExtension.start(BootstrapExtension.java:20)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> .........
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFLY-4784) @Transactional annotation on stereotype leads to error "ARJUNA016107: Expected an @Transactional annotation at class and/or method level"
by Alexander Morozov (JIRA)
Alexander Morozov created WFLY-4784:
---------------------------------------
Summary: @Transactional annotation on stereotype leads to error "ARJUNA016107: Expected an @Transactional annotation at class and/or method level"
Key: WFLY-4784
URL: https://issues.jboss.org/browse/WFLY-4784
Project: WildFly
Issue Type: Bug
Components: CDI / Weld, Transactions
Affects Versions: 9.0.0.CR1, 8.2.0.Final
Environment: JDK 1.7u72 x64, Windows 8.1 Professional
Reporter: Alexander Morozov
Assignee: Stuart Douglas
Priority: Critical
It is seems that CDI Transactional extesion doesn't support well @Transactional annotation on CDI stereotypes. JTA transaction is created by library interceptor, but in case of exception on component's side, _com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(...)_ method failed to locate @Transactional annotation on target component. It leads to exception like that
{code}
java.lang.RuntimeException: ARJUNA016107: Expected an @Transactional annotation at class and/or method level
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(TransactionalInterceptorBase.java:83)
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.handleException(TransactionalInterceptorBase.java:118)
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInCallerTx(TransactionalInterceptorBase.java:106)
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorMandatory.intercept(TransactionalInterceptorMandatory.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56)
at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79)
at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68)
at com.mycompany.wildfly.jta.cdi.UserEventDispatcher$Proxy$_$$_WeldSubclass.dispatch(Unknown Source)
at com.mycompany.wildfly.jta.cdi.UserEventDispatcher$Proxy$_$$_WeldClientProxy.dispatch(Unknown Source)
at com.mycompany.wildfly.jta.cdi.UserApplicationService.addUser(UserApplicationService.java:18)
at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldSubclass.addUser$$super(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:49)
at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:77)
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:92)
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56)
at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79)
at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68)
at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldSubclass.addUser(Unknown Source)
at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldClientProxy.addUser(Unknown Source)
at com.mycompany.wildfly.jta.cdi.BootstrapExtension.start(BootstrapExtension.java:20)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
.........
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFCORE-671) Configuration change reporting
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-671?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-671:
-----------------------------------------
This is really audit logging data, so probably this should just be done with an in-memory handler for the existing audit logging feature. That restricts its use to SuperUser and Auditor, and ties the configuration aspect into the audit logging config. That makes the fact that a persistent log should be used for long term recording more obvious.
Restricting use to SuperUser and Auditor also removes any need to elide any data from the output, as those roles can see anything.
> Configuration change reporting
> ------------------------------
>
> Key: WFCORE-671
> URL: https://issues.jboss.org/browse/WFCORE-671
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 2.0.0.Beta1
>
>
> Allow administrators to view the last N (configurable) changes in the domain/server configurations made by other authorized administrators.
> Proper RBAC eliding of information should be done, a la what was done with the boot error reporting feature.
> I see this as being very similar to the boot error reporting.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFCORE-671) Configuration change reporting
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-671?page=com.atlassian.jira.plugin... ]
Brian Stansberry edited comment on WFCORE-671 at 6/15/15 1:34 PM:
------------------------------------------------------------------
Restrict N. No writing to disk. We have an audit log feature if extensive analysis of changes is desired.
This is sensitive data; we have to treat it very carefully.
was (Author: brian.stansberry):
No writing to disk. We have an audit log.
This is sensitive data; we have to treat it very carefully.
> Configuration change reporting
> ------------------------------
>
> Key: WFCORE-671
> URL: https://issues.jboss.org/browse/WFCORE-671
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 2.0.0.Beta1
>
>
> Allow administrators to view the last N (configurable) changes in the domain/server configurations made by other authorized administrators.
> Proper RBAC eliding of information should be done, a la what was done with the boot error reporting feature.
> I see this as being very similar to the boot error reporting.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFCORE-671) Configuration change reporting
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-671?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-671:
-----------------------------------------
No writing to disk. We have an audit log.
This is sensitive data; we have to treat it very carefully.
> Configuration change reporting
> ------------------------------
>
> Key: WFCORE-671
> URL: https://issues.jboss.org/browse/WFCORE-671
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 2.0.0.Beta1
>
>
> Allow administrators to view the last N (configurable) changes in the domain/server configurations made by other authorized administrators.
> Proper RBAC eliding of information should be done, a la what was done with the boot error reporting feature.
> I see this as being very similar to the boot error reporting.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFCORE-671) Configuration change reporting
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-671?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet commented on WFCORE-671:
------------------------------------------
If N gets a high value this might have an impact on the memory usage, should we restrict the value or store some of the content to disk ?
> Configuration change reporting
> ------------------------------
>
> Key: WFCORE-671
> URL: https://issues.jboss.org/browse/WFCORE-671
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 2.0.0.Beta1
>
>
> Allow administrators to view the last N (configurable) changes in the domain/server configurations made by other authorized administrators.
> Proper RBAC eliding of information should be done, a la what was done with the boot error reporting feature.
> I see this as being very similar to the boot error reporting.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (DROOLS-818) Listeners declared in kmodule.xml are not registered in StatelessKieSession
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-818:
----------------------------------
Summary: Listeners declared in kmodule.xml are not registered in StatelessKieSession
Key: DROOLS-818
URL: https://issues.jboss.org/browse/DROOLS-818
Project: Drools
Issue Type: Bug
Reporter: Mario Fusco
Assignee: Mario Fusco
Listener declared in kmodule.xml as in the following snippet of XML works on stateful KieSession, but are not registered on stateless ones.
{code}
<ksession name="statelessKieSession1" type="stateless">
<listeners>
<ruleRuntimeEventListener type="com.esrx.ref.testproject.TestRuleRuntimeEventListener"/>
</listeners>
</ksession>
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFCORE-759) Improve encapsulation of logic for handling ordered resource children
by Paul Ferraro (JIRA)
Paul Ferraro created WFCORE-759:
-----------------------------------
Summary: Improve encapsulation of logic for handling ordered resource children
Key: WFCORE-759
URL: https://issues.jboss.org/browse/WFCORE-759
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Affects Versions: 2.0.0.Alpha4
Reporter: Paul Ferraro
Assignee: Kabir Khan
Currently, a resource that has ordered child resources needs to define this logic in 3 places:
# The ResourceDefinition needs to indicate that it supports indexed adds (solely for adding the appropriate add-index description) by overwriting SimpleResourceDefinition.isOrderedChildResource()
# The add operation handler of the parent resource needs to override AbstractAddStepHandler.getResourceCreator() to provide an implementation of OrderedResourceCreator that dictates which child types will be ordered
# The add operation handler of the ordered child resource needs to override AbstractAddStepHandler.getResourceCreator() to provide an implementation of OrderedResourceCreator that indicates that the resource supports add-index.
IMO, this seems like poor encapsulation. If we added a ImmutableManagementResourceRegistration.isOrderedChildResource() method, then the AbstractAddStepHandler can query the resource registration to determine whether the current resource supports the add-index parameter, and to see which child types are ordered. This would eliminate the need for subsystems to do #2 and #3 - based solely on the information provided by #1.
Also, indicating this behavior (i.e. #1) via overriding a protected method also seems a little hacky/tacked-on. This method is only read by the SimpleResourceDefinition constructor - which means that this information is more appropriately provided by the constructor. I assume it was done this way since the SimpleResourceDefinition constructors are already overly polluted/complex. Why not instead define this behavior by a ManagementResourceRegistration.registerOrderedSubModel(ResourceDefinition) method?
Thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFCORE-758) ClassNotFoundException: javax.sql.RowSet
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-758?page=com.atlassian.jira.plugin... ]
David Lloyd moved WFLY-4783 to WFCORE-758:
------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-758 (was: WFLY-4783)
Affects Version/s: (was: 9.0.0.CR2)
Component/s: Modules
(was: Web (Undertow))
> ClassNotFoundException: javax.sql.RowSet
> ----------------------------------------
>
> Key: WFCORE-758
> URL: https://issues.jboss.org/browse/WFCORE-758
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules
> Environment: Windows 7, Java 8u45 (64 bit)
> Reporter: Greg Jewell
> Assignee: Stuart Douglas
>
> I downloaded the WF9 CR2 release this morning and have been testing functionality. A new exception has appeared with this release. This did not happen with a source release that was downloaded and built between CR1 and CR2, so was just introduced in the last week or so.
> We have a Flex application that is throwing the following exception as it's being loaded:
> [BlazeDS]javax/sql/RowSet
> {noformat}
> java.lang.NoClassDefFoundError: javax/sql/RowSet
> at flex.messaging.io.amf.Amf3Output.writeObject(Amf3Output.java:198)
> at flex.messaging.messages.AbstractMessage.writeExternal(AbstractMessage.java:444)
> at flex.messaging.messages.AsyncMessage.writeExternal(AsyncMessage.java:140)
> at flex.messaging.messages.AcknowledgeMessage.writeExternal(AcknowledgeMessage.java:94)
> at flex.messaging.messages.AcknowledgeMessageExt.writeExternal(AcknowledgeMessageExt.java:55)
> at flex.messaging.io.amf.Amf3Output.writePropertyProxy(Amf3Output.java:594)
> at flex.messaging.io.amf.Amf3Output.writeCustomObject(Amf3Output.java:532)
> at flex.messaging.io.amf.Amf3Output.writeObject(Amf3Output.java:112)
> at flex.messaging.io.amf.Amf0Output.writeObject(Amf0Output.java:206)
> at flex.messaging.io.amf.AmfMessageSerializer.writeObject(AmfMessageSerializer.java:196)
> at flex.messaging.io.amf.AmfMessageSerializer.writeBody(AmfMessageSerializer.java:186)
> at flex.messaging.io.amf.AmfMessageSerializer.writeMessage(AmfMessageSerializer.java:142)
> at flex.messaging.endpoints.amf.SerializationFilter.invoke(SerializationFilter.java:198)
> at flex.messaging.endpoints.BaseHTTPEndpoint.service(BaseHTTPEndpoint.java:291)
> at flex.messaging.MessageBrokerServlet.service(MessageBrokerServlet.java:353)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:274)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:253)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.ClassNotFoundException: javax.sql.RowSet from [Module "deployment.Test.ear.test.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> ... 43 more
> {noformat}
> - See more at: https://developer.jboss.org/thread/260451#sthash.LJ3DCVsa.dpuf
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months