[JBoss JIRA] (WFLY-9884) NoSuchElementException when deploying EAR file
by Jacob Ilsø (JIRA)
Jacob Ilsø created WFLY-9884:
--------------------------------
Summary: NoSuchElementException when deploying EAR file
Key: WFLY-9884
URL: https://issues.jboss.org/browse/WFLY-9884
Project: WildFly
Issue Type: Bug
Affects Versions: 11.0.0.Final
Environment: Windows 8.1 Enterprise.
Reporter: Jacob Ilsø
Assignee: Jason Greene
Attachments: log.txt
I have an EAR file with several "@Singleton @Startup" beans. Each bean having a number of @Inject and @Resource fields. When I deploy the EAR in WildFly 11 it sometimes fails with a NoSuchElementException (see [^log.txt] for a full stacktrace).
I cannot reproduce it consistently but it seems to only happen on a "clean" WildFly installation. I haven't seen this on earlier versions of WildFly.
Let me know if you want me to try to build an EAR for reproducing this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9883) EAR deployments are creating unnecessary and wrong EJB ModuleDeployment services
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-9883:
------------------------------------
Summary: EAR deployments are creating unnecessary and wrong EJB ModuleDeployment services
Key: WFLY-9883
URL: https://issues.jboss.org/browse/WFLY-9883
Project: WildFly
Issue Type: Bug
Components: EJB
Reporter: Stuart Douglas
Assignee: Stuart Douglas
This is being installed using archive name as both the app and module name, if there is an archive in the deployment with a similar name then this can race with the service for that module, and if the EAR's module ends up being the last one to start then the EJB's will not be available.
This is causing intermittent failures in NestedRemoteContextTestCase
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9880) ServletContainerInitializer@onStartup is not invoked for deployment
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9880?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-9880.
----------------------------------
Resolution: Rejected
With a corrected jboss-deployment-structure.xml I get the following:
15:32:46,338 INFO [org.jboss.qa.startstop.standalone.web.resources.SlowServletInit] (ServerService Thread Pool -- 64) Servlet init started
15:32:46,338 INFO [org.jboss.qa.startstop.standalone.web.resources.SlowServletInit] (ServerService Thread Pool -- 64) Servlet init finished
> ServletContainerInitializer@onStartup is not invoked for deployment
> -------------------------------------------------------------------
>
> Key: WFLY-9880
> URL: https://issues.jboss.org/browse/WFLY-9880
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 12.0.0.Beta1
> Reporter: Jan Stourac
> Assignee: Stuart Douglas
> Attachments: deployment-with-dep.war, module.xml, servlet-container-init.jar
>
>
> The {{ServletContainerInitializer@onStartup}} is not invoked for deployment. See {{Steps to Reproduce}}.
> Problematic part seems to be on [this line|https://github.com/undertow-io/undertow/blob/1706a5f41adb8f1a719617c...] in Undertow
> {code}
> //then run the SCI's
> ---> for (final ServletContainerInitializerInfo sci : deploymentInfo.getServletContainerInitializers()) {
> final InstanceHandle<? extends ServletContainerInitializer> instance = sci.getInstanceFactory().createInstance();
> try {
> instance.getInstance().onStartup(sci.getHandlesTypes(), servletContext);
> } finally {
> instance.release();
> }
> }
> {code}
> It looks like calling {{deploymentInfo.getServletContainerInitializers()}} does not include our deployment and simply ignores it.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9880) ServletContainerInitializer@onStartup is not invoked for deployment
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9880?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-9880:
--------------------------------------
You need to import services when you add the dependency.
> ServletContainerInitializer@onStartup is not invoked for deployment
> -------------------------------------------------------------------
>
> Key: WFLY-9880
> URL: https://issues.jboss.org/browse/WFLY-9880
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 12.0.0.Beta1
> Reporter: Jan Stourac
> Assignee: Stuart Douglas
> Attachments: deployment-with-dep.war, module.xml, servlet-container-init.jar
>
>
> The {{ServletContainerInitializer@onStartup}} is not invoked for deployment. See {{Steps to Reproduce}}.
> Problematic part seems to be on [this line|https://github.com/undertow-io/undertow/blob/1706a5f41adb8f1a719617c...] in Undertow
> {code}
> //then run the SCI's
> ---> for (final ServletContainerInitializerInfo sci : deploymentInfo.getServletContainerInitializers()) {
> final InstanceHandle<? extends ServletContainerInitializer> instance = sci.getInstanceFactory().createInstance();
> try {
> instance.getInstance().onStartup(sci.getHandlesTypes(), servletContext);
> } finally {
> instance.release();
> }
> }
> {code}
> It looks like calling {{deploymentInfo.getServletContainerInitializers()}} does not include our deployment and simply ignores it.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9346) Race condition during ORB startup
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9346?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-9346.
----------------------------------
Resolution: Done
> Race condition during ORB startup
> ---------------------------------
>
> Key: WFLY-9346
> URL: https://issues.jboss.org/browse/WFLY-9346
> Project: WildFly
> Issue Type: Bug
> Components: IIOP, Security
> Affects Versions: 11.0.0.CR1
> Reporter: Tomasz Adamski
> Assignee: Tomasz Adamski
> Fix For: 12.0.0.CR1
>
>
> In the code, there is not direct dependency between ORB service and the security which occasionally may lead to the following error:
> {code}
> 2017-09-10 22:06:57,015 WARNING [javax.enterprise.resource.corba._INITIALIZING_.rpc.presentation] (MSC service thread 1-3) "IOP01210227: (BAD_OPERATION) Error in running ORB configurator": org.omg.CORBA.BAD_OPERATION: vmcid: SUN minor code: 227 completed: No
> at com.sun.corba.se.impl.logging.ORBUtilSystemException.orbConfiguratorError(ORBUtilSystemException.java:558) [openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
> at com.sun.corba.se.impl.logging.ORBUtilSystemException.orbConfiguratorError(ORBUtilSystemException.java:576) [openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
> at com.sun.corba.se.impl.orb.ORBImpl.postInit(ORBImpl.java:485) [openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
> at com.sun.corba.se.impl.orb.ORBImpl.set_parameters(ORBImpl.java:543) [openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
> at org.omg.CORBA.ORB.init(ORB.java:353) [openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
> at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:126) [wildfly-iiop-openjdk-7.1.0.GA-redhat-SNAPSHOT.jar:7.1.0.GA-redhat-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) [jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_144]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_144]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_144]
> Caused by: java.lang.RuntimeException: javax.naming.ConfigurationException: WFLYIIOP0051: Error configuring domain socket factory: failed to lookup JSSE security domain
> at org.wildfly.iiop.openjdk.security.LegacySSLSocketFactory.setORB(LegacySSLSocketFactory.java:86) [wildfly-iiop-openjdk-7.1.0.GA-redhat-SNAPSHOT.jar:7.1.0.GA-redhat-SNAPSHOT]
> at com.sun.corba.se.impl.orb.ORBConfiguratorImpl.initializeTransport(ORBConfiguratorImpl.java:271) [openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
> at com.sun.corba.se.impl.orb.ORBConfiguratorImpl.configure(ORBConfiguratorImpl.java:149) [openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
> at com.sun.corba.se.impl.orb.ORBImpl.postInit(ORBImpl.java:483) [openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
> ... 8 more
> Caused by: javax.naming.ConfigurationException: WFLYIIOP0051: Error configuring domain socket factory: failed to lookup JSSE security domain
> ... 12 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3634) ActiveOperationImpl should remove the operation from the handler before signalling the result handler
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3634?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3634:
-------------------------------------
Priority: Optional (was: Major)
Switching this to optional and I'll probably reject it.
Turns out this isn't what was causing the failures I was seeing.
And closing a RemotingModelControllerClient, before any active operations are cancelled, the channel to the server is closed, which is going to cause the server-side channel to close, affecting active operations.
So this change is valid in a theoretical sense but will likely not have any practical benefit.
Fix is at https://github.com/bstansberry/wildfly-core/tree/WFCORE-3634
> ActiveOperationImpl should remove the operation from the handler before signalling the result handler
> -----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3634
> URL: https://issues.jboss.org/browse/WFCORE-3634
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Optional
>
> Caution: this is a theoretical solution to a problem.
> I'm seeing a fairly frequent problem with the use of org.wildfly.core.testrunner.Server.reload() where the reload is proceeding but the server log shows the following, followed by various undesirable things and a test failure of one sort or another:
> {code}
> &#27;[0m&#27;[0m07:50:27,581 INFO [org.jboss.as.protocol] (management I/O-2) WFLYPRT0057: cancelled task by interrupting thread Thread[management-handler-thread - 1,5,management-handler-thread]
> {code}
> I believe the issue is that Server.executeReload is closing the client in a finally block immediately after reading the response to reload. But the server sends the response to reload *early* so on the server side the op is still in progress. The client-side close of the client is resulting in cancellation of that still in-progress op.
> But why is the close of the client causing cancellation? The client has received the response; why is it still tracking the operation? My theory is that the ResultHandler created by ActiveOperationImpl is publishing the result (or failure) before it removes the active operation from tracking in a finally block. Doing this in the opposite order would mean the active op would be cleared before the result is published.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9869) Pure HTTP EJB invocation not working
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9869?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-9869:
------------------------------------
Assignee: Stuart Douglas
> Pure HTTP EJB invocation not working
> ------------------------------------
>
> Key: WFLY-9869
> URL: https://issues.jboss.org/browse/WFLY-9869
> Project: WildFly
> Issue Type: Quality Risk
> Components: EJB
> Affects Versions: 11.0.0.Final
> Environment: Debian 9 - 64-bit
> Reporter: Andre Izu
> Assignee: Stuart Douglas
> Labels: ejb, pure_http
> Attachments: ejb-http-client.zip
>
>
> I have been trying to make the "pure" http EJB invocation from a remote server instance, without success.
> The client module was built inside a war file, while the server artifact was build in an ear file.
> When I set the Context.PROVIDER_URL to "remote+http://127.0.0.1:8080" or "http://localhost:8080/wildfly-services", the remote invocation works fine via main() method.
> When I set the Context.PROVIDER_URL to "remote+http://127.0.0.1:8080", the remote invocation works fine via http://localhost:8080/web/index.jsp (client application calling server application)
> Now when I set the Context.PROVIDER_URL to "http://localhost:8080/wildfly-services", the remote invocation via http://localhost:8080/web/index.jsp (client application calling server application) returns:
> {panel:title=Client application calling server application}
> 2018-01-05 15:30:07,346 INFO [stdout] (default task-44) jndiName: ejb:wejb/wejb/CalculatorEJB!br.com.server.Calculator
> 2018-01-05 15:30:07,351 INFO [stdout] (default task-44) Proxy for remote EJB StatelessEJBLocator for "wejb/wejb/CalculatorEJB", view is interface br.com.server.Calculator, affinity is None
> 2018-01-05 15:30:07,352 ERROR [io.undertow.request] (default task-44) UT005023: Exception handling request to /web/: org.apache.jasper.JasperException: org.jboss.ejb.client.RequestSendFailedException: EJBCLIENT000409: No more destinations are available
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:473)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
> 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:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 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 org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$852/801580157.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 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)
> Caused by: org.jboss.ejb.client.RequestSendFailedException: EJBCLIENT000409: No more destinations are available
> at org.jboss.ejb.client.EJBReceiverInvocationContext$ResultProducer$Failed.getResult(EJBReceiverInvocationContext.java:151)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:567)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocationResult(RemotingEJBClientInterceptor.java:56)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocationResult(TransactionPostDiscoveryInterceptor.java:133)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocationResult(DiscoveryEJBClientInterceptor.java:118)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocationResult(NamingEJBClientInterceptor.java:78)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:172)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:907)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:165)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:100)
> at com.sun.proxy.$Proxy61.calculateInterest(Unknown Source)
> at br.com.client.RemoteEJBClient.main(RemoteEJBClient.java:20)
> at br.com.client.RemoteEJBClient.func(RemoteEJBClient.java:14)
> at org.apache.jsp.index_jsp._jspService(index_jsp.java:99)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> ... 47 more
> Suppressed: javax.ejb.NoSuchEJBException: EJBCLIENT000024: No EJB receiver available for handling destination "http://localhost:8080/wildfly-services"
> at org.jboss.ejb.client.EJBClientContext.resolveReceiver(EJBClientContext.java:571)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:438)
> at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocation(RemotingEJBClientInterceptor.java:51)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocation(TransactionPostDiscoveryInterceptor.java:79)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocation(DiscoveryEJBClientInterceptor.java:90)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocation(NamingEJBClientInterceptor.java:66)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:165)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.EJBClientInvocationContext$$Lambda$915/72354668.accept(Unknown Source)
> at org.wildfly.common.context.Contextual.runExConsumer(Contextual.java:203)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequestInitial(EJBClientInvocationContext.java:302)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:161)
> ... 55 more
> {panel}
> This behaviour is reproduceable with the attached project. One detail not mentioned in the jboss forum is that I started wildfly 11 with standalone-full.xml
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months