[JBoss JIRA] (WFCORE-5073) When using Galleon to provision Wildfly with core-server+managment layers, the availability of the Admin console is wrongly advertised to the user
by Fabio Burzigotti (Jira)
[ https://issues.redhat.com/browse/WFCORE-5073?page=com.atlassian.jira.plug... ]
Fabio Burzigotti commented on WFCORE-5073:
------------------------------------------
Thanks [~brian.stansberry] for moving the issue to the right project and [~dlofthouse] for raising that point.
> When using Galleon to provision Wildfly with core-server+managment layers, the availability of the Admin console is wrongly advertised to the user
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-5073
> URL: https://issues.redhat.com/browse/WFCORE-5073
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 12.0.2.Final, 13.0.0.Beta2
> Reporter: Fabio Burzigotti
> Assignee: Brian Stansberry
> Priority: Major
>
> When using Galleon to provision a Wildfly instance which would include just the {{core-server}} and {{managment}} layers, the LOG will trace the following lines:
> {code}
> ...
> 15:38:17,219 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 20.0.1.Final (WildFly Core 12.0.3.Final) started in 1625ms - Started 86 of 89 services (27 services are lazy, passive or on-demand)
> 15:38:17,221 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
> 15:38:17,221 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
> {code}
> This is a wrong message for the end user because the managment interface will be available at the reported URL but the Admin console won't, returning a HTTP 404 status code.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-13719) Error deploying EJB in WildFly when using @EJB
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13719?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-13719:
-----------------------------------
[~soul2zimate] Your draft looks good. I've just checked a few docs-related fields in this issue (affects release notes, migration, etc)
> Error deploying EJB in WildFly when using @EJB
> ----------------------------------------------
>
> Key: WFLY-13719
> URL: https://issues.redhat.com/browse/WFLY-13719
> Project: WildFly
> Issue Type: Bug
> Components: EE, EJB
> Affects Versions: 20.0.1.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Major
> Attachments: reproducer.zip
>
>
> The following example does *not* get deployed on Wildfly 20.0.1.Final (since WFLY 13.0.0.Final):
> ~~~
> public class PleaseIgnoreMeThanks
> { @EJB private NonExistentEjbExampleLocal nonExistentEjbExample; }
> ~~~
> The issue seems to be on the @EJB annotation.
>
> Generated error:
> {code:xml}
> 10:19:19,025 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."ejb-in-war.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."ejb-in-war.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "ejb-in-war.war"
> at org.jboss.as.server@12.0.3.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:189)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0406: No EJB found with interface of type 'org.jboss.as.quickstarts.ejbTimer.NonExistentEjbExampleLocal' for binding org.jboss.as.quickstarts.ejbTimer.PleaseIgnoreMeThanks/nonExistentEjbExample
> at org.jboss.as.ejb3@20.0.1.Final//org.jboss.as.ejb3.deployment.processors.EjbInjectionSource.getResourceValue(EjbInjectionSource.java:90)
> at org.jboss.as.ee@20.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:269)
> at org.jboss.as.ee@20.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:200)
> at org.jboss.as.server@12.0.3.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:182)
> ... 8 more
> ~~{code}
>
> !moz-extension://4f9dc55f-98eb-44f6-97f9-1c9d85f3a188/icons/logo.png!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-13719) Error deploying EJB in WildFly when using @EJB
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13719?page=com.atlassian.jira.plugi... ]
Cheng Fang updated WFLY-13719:
------------------------------
Affects: Documentation (Ref Guide, User Guide, etc.),Release Notes,Migration
> Error deploying EJB in WildFly when using @EJB
> ----------------------------------------------
>
> Key: WFLY-13719
> URL: https://issues.redhat.com/browse/WFLY-13719
> Project: WildFly
> Issue Type: Bug
> Components: EE, EJB
> Affects Versions: 20.0.1.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Major
> Attachments: reproducer.zip
>
>
> The following example does *not* get deployed on Wildfly 20.0.1.Final (since WFLY 13.0.0.Final):
> ~~~
> public class PleaseIgnoreMeThanks
> { @EJB private NonExistentEjbExampleLocal nonExistentEjbExample; }
> ~~~
> The issue seems to be on the @EJB annotation.
>
> Generated error:
> {code:xml}
> 10:19:19,025 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."ejb-in-war.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."ejb-in-war.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "ejb-in-war.war"
> at org.jboss.as.server@12.0.3.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:189)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0406: No EJB found with interface of type 'org.jboss.as.quickstarts.ejbTimer.NonExistentEjbExampleLocal' for binding org.jboss.as.quickstarts.ejbTimer.PleaseIgnoreMeThanks/nonExistentEjbExample
> at org.jboss.as.ejb3@20.0.1.Final//org.jboss.as.ejb3.deployment.processors.EjbInjectionSource.getResourceValue(EjbInjectionSource.java:90)
> at org.jboss.as.ee@20.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:269)
> at org.jboss.as.ee@20.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:200)
> at org.jboss.as.server@12.0.3.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:182)
> ... 8 more
> ~~{code}
>
> !moz-extension://4f9dc55f-98eb-44f6-97f9-1c9d85f3a188/icons/logo.png!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-13736) [GSS](7.2.z) WFLYWELD0041: WeldContainer is not started when redeploying
by Stuart Douglas (Jira)
[ https://issues.redhat.com/browse/WFLY-13736?page=com.atlassian.jira.plugi... ]
Stuart Douglas reassigned WFLY-13736:
-------------------------------------
Assignee: Stuart Douglas (was: Bartosz Baranowski)
> [GSS](7.2.z) WFLYWELD0041: WeldContainer is not started when redeploying
> ------------------------------------------------------------------------
>
> Key: WFLY-13736
> URL: https://issues.redhat.com/browse/WFLY-13736
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Priority: Major
>
> Deploy 2 applications where:
> - api is a static module containing EJB Local Interface and transfer objects
> - app2.war has an EJB with a Local interface
> - app1.war has a Servlet that uses @EJB to inject the EJB in app2, it also has a CDI bean with @RequestScoped on it (But the CDI bean is not referenced by anything)
> Start JBoss
> touch app2.war to trigger redeployment and it will fail with the error below.
> It seems redeploying app2 triggers app1 to restart a service based on the logs.
> Note the error only occurs when the CDI bean in app1 has the @RequestScoped annotation
> {code}
> 14:26:38,290 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.2.6.GA (WildFly Core 6.0.21.Final-redhat-00001) started in 4056ms - Started 537 of 720 services (330 services are lazy, passive or on-demand)
> 14:26:43,309 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 73) WFLYUT0022: Unregistered web context: '/app1' from server 'default-server'
> 14:26:43,309 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 7) WFLYUT0022: Unregistered web context: '/app2' from server 'default-server'
> 14:26:43,310 INFO [Servlet] (ServerService Thread Pool -- 73) ***** DESTROY ******
> 14:26:43,353 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0028: Stopped deployment app2.war (runtime-name: app2.war) in 47ms
> 14:26:43,356 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "app2.war" (runtime-name: "app2.war")
> 14:26:43,410 INFO [org.jboss.weld.deployer] (MSC service thread 1-4) WFLYWELD0003: Processing weld deployment app2.war
> 14:26:43,428 INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-4) WFLYEJB0473: JNDI bindings for session bean named 'HelloEJB' in deployment unit 'deployment "app2.war"' are as follows:
> java:global/app2/HelloEJB!api.HelloLocal
> java:app/app2/HelloEJB!api.HelloLocal
> java:module/HelloEJB!api.HelloLocal
> ejb:/app2/HelloEJB!api.HelloLocal
> java:global/app2/HelloEJB
> java:app/app2/HelloEJB
> java:module/HelloEJB
> 14:26:43,479 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."app1.war".component."org.jboss.weld.module.web.servlet.WeldInitialListener".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."app1.war".component."org.jboss.weld.module.web.servlet.WeldInitialListener".WeldInstantiator: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: WFLYWELD0041: WeldContainer is not started
> at org.jboss.as.weld.WeldBootstrapService.getBeanManager(WeldBootstrapService.java:185)
> at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:97)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> ... 6 more
> ...
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-13736) [GSS](7.2.z) WFLYWELD0041: WeldContainer is not started when redeploying
by Stuart Douglas (Jira)
[ https://issues.redhat.com/browse/WFLY-13736?page=com.atlassian.jira.plugi... ]
Stuart Douglas moved JBEAP-20035 to WFLY-13736:
-----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-13736 (was: JBEAP-20035)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CDI / Weld
(was: CDI / Weld)
Affects Version/s: (was: 7.2.6.GA)
Fix Version/s: (was: 7.2.10.GA)
> [GSS](7.2.z) WFLYWELD0041: WeldContainer is not started when redeploying
> ------------------------------------------------------------------------
>
> Key: WFLY-13736
> URL: https://issues.redhat.com/browse/WFLY-13736
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Reporter: Stuart Douglas
> Assignee: Bartosz Baranowski
> Priority: Major
>
> Deploy 2 applications where:
> - api is a static module containing EJB Local Interface and transfer objects
> - app2.war has an EJB with a Local interface
> - app1.war has a Servlet that uses @EJB to inject the EJB in app2, it also has a CDI bean with @RequestScoped on it (But the CDI bean is not referenced by anything)
> Start JBoss
> touch app2.war to trigger redeployment and it will fail with the error below.
> It seems redeploying app2 triggers app1 to restart a service based on the logs.
> Note the error only occurs when the CDI bean in app1 has the @RequestScoped annotation
> {code}
> 14:26:38,290 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.2.6.GA (WildFly Core 6.0.21.Final-redhat-00001) started in 4056ms - Started 537 of 720 services (330 services are lazy, passive or on-demand)
> 14:26:43,309 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 73) WFLYUT0022: Unregistered web context: '/app1' from server 'default-server'
> 14:26:43,309 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 7) WFLYUT0022: Unregistered web context: '/app2' from server 'default-server'
> 14:26:43,310 INFO [Servlet] (ServerService Thread Pool -- 73) ***** DESTROY ******
> 14:26:43,353 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0028: Stopped deployment app2.war (runtime-name: app2.war) in 47ms
> 14:26:43,356 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "app2.war" (runtime-name: "app2.war")
> 14:26:43,410 INFO [org.jboss.weld.deployer] (MSC service thread 1-4) WFLYWELD0003: Processing weld deployment app2.war
> 14:26:43,428 INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-4) WFLYEJB0473: JNDI bindings for session bean named 'HelloEJB' in deployment unit 'deployment "app2.war"' are as follows:
> java:global/app2/HelloEJB!api.HelloLocal
> java:app/app2/HelloEJB!api.HelloLocal
> java:module/HelloEJB!api.HelloLocal
> ejb:/app2/HelloEJB!api.HelloLocal
> java:global/app2/HelloEJB
> java:app/app2/HelloEJB
> java:module/HelloEJB
> 14:26:43,479 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."app1.war".component."org.jboss.weld.module.web.servlet.WeldInitialListener".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."app1.war".component."org.jboss.weld.module.web.servlet.WeldInitialListener".WeldInstantiator: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: WFLYWELD0041: WeldContainer is not started
> at org.jboss.as.weld.WeldBootstrapService.getBeanManager(WeldBootstrapService.java:185)
> at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:97)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> ... 6 more
> ...
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-13735) Use of thread pools with EJB remote element needs attention
by Richard Achmatowicz (Jira)
Richard Achmatowicz created WFLY-13735:
------------------------------------------
Summary: Use of thread pools with EJB remote element needs attention
Key: WFLY-13735
URL: https://issues.redhat.com/browse/WFLY-13735
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 21.0.0.Beta1
Reporter: Richard Achmatowicz
Assignee: Cheng Fang
The EJB3RemoteResourceDefinition defines two related attributes:
* an attribute thread-pool-name which is optional and has no default
* an attribute execute-in-worker, which is also optional but has a default "true"
When execute-in-worker == false, the add handler expects the thread pool to be available (the remote connector service introduces a capability dependency on it), but because thread-pool-name is optional, this may not be the case.
If execute-in-worker == false, we need to check and throw an error message if a thread pool attribute value is not available, as we can no longer satisfy this condition (in other words, we cannot delegate the work of processing the method to a thread in the non-existent thread pool).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-13723) Many Jakarta EE 8 TCK tests are failing due to "Unknown service name jboss.ejb"
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13723?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz edited comment on WFLY-13723 at 8/3/20 7:56 PM:
--------------------------------------------------------------------
[~cfang] [~smarlow] Pretty sure I found the problem. The thread pool capabilities are dynamic. When the capability requirement for the thread pool is defined for the remote service, the capability requirement method uses the static form of the method and not the dynamic form, so instead of looking for a capability with name org.wildfly.threads.executor.ejb3.default, it looks for org.wildfly.threads.executor.ejb3, which does not exist as a static capability. This is a one line fix.
It didn't show up in the Wildfly testsuite as we don't seem to have a test which exercises execute-in-worker="false" on the remote element, whereas the CTS does.
was (Author: rachmato):
[~cfang] [~smarlow] Pretty sure I found the problem. The thread pool capabilities are dynamic. When the capability requirement for the thread pool is defined for the remote service, the capability requirement method uses the static form of the method and not the dynamic form, so instead of looking for a capability with name org.wildfly.threads.executor.ejb3.default, it looks for org.wildfly.threads.executor.ejb3, which does not exist as a static capability. This is a one line fix.
It didn't show up in the Wildfly testsuite as we don't seem to have a test which exercises execute-in-worker="false", whereas the CTS does.
> Many Jakarta EE 8 TCK tests are failing due to "Unknown service name jboss.ejb"
> -------------------------------------------------------------------------------
>
> Key: WFLY-13723
> URL: https://issues.redhat.com/browse/WFLY-13723
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Scott Marlow
> Assignee: Cheng Fang
> Priority: Major
>
> I am now able to publicly discuss Jakarta EE 8 TCK failures, so am creating this issue to request a fix for the below "Unknown service name jboss.ejb" error.
> {code}
> \u001b[0m\u001b[0m22:18:24,546 INFO [org.jboss.as.server] (Thread-41) WFLYSRV0010: Deployed "jta_ejb_vehicle.ear" (runtime-name : "jta_ejb_vehicle.ear")
> \u001b[0m\u001b[0m22:18:24,580 INFO [stdout] (Thread-186) ************************************************************
> \u001b[0m\u001b[0m22:18:24,580 INFO [stdout] (Thread-186) * props file set to "/tmp/hudson-cts-props.txt"
> \u001b[0m\u001b[0m22:18:24,580 INFO [stdout] (Thread-186) ************************************************************
> \u001b[0m\u001b[0m22:18:24,628 INFO [org.wildfly.naming] (Thread-186) WildFly Naming version 1.0.13.Final
> \u001b[0m\u001b[0m22:18:24,687 INFO [org.jboss.ejb.client] (Thread-186) JBoss EJB Client version 4.0.33.Final
> \u001b[0m\u001b[0m22:18:25,082 INFO [stdout] (Thread-186) 07-30-2020 22:18:25: ERROR: Test failed
> \u001b[0m\u001b[0m22:18:25,084 INFO [stdout] (Thread-186) 07-30-2020 22:18:25: ERROR: javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB StatelessEJBLocator for "jta_ejb_vehicle/jta_ejb_vehicle_ejb/com_sun_ts_tests_common_vehicle_ejb_EJBVehicle", view is interface com.sun.ts.tests.common.vehicle.ejb.EJBVehicleHome, affinity is None
> \u001b[0m\u001b[0m22:18:25,084 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:622)
> \u001b[0m\u001b[0m22:18:25,084 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:553)
> \u001b[0m\u001b[0m22:18:25,084 INFO [stdout] (Thread-186) at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocationResult(RemotingEJBClientInterceptor.java:57)
> \u001b[0m\u001b[0m22:18:25,084 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:624)
> \u001b[0m\u001b[0m22:18:25,084 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:553)
> \u001b[0m\u001b[0m22:18:25,084 INFO [stdout] (Thread-186) at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocationResult(TransactionPostDiscoveryInterceptor.java:148)
> \u001b[0m\u001b[0m22:18:25,084 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:624)
> \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:553)
> \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocationResult(DiscoveryEJBClientInterceptor.java:137)
> \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:624)
> \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:553)
> \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocationResult(NamingEJBClientInterceptor.java:87)
> \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:624)
> \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:553)
> \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:212)
> \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:624)
> \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:553)
> \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:995)
> \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:191)
> \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125)
> \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at com.sun.proxy.$Proxy19.create(Unknown Source)
> \u001b[0m\u001b[0m22:18:25,085 INFO [stdout] (Thread-186) at com.sun.ts.tests.common.vehicle.ejb.EJBVehicleRunner.run(EJBVehicleRunner.java:66)
> \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:105)
> \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:486)
> \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:209)
> \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at com.sun.ts.lib.harness.EETest.run(EETest.java:285)
> \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at com.sun.ts.tests.common.vehicle.VehicleClient.main(VehicleClient.java:38)
> \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at java.lang.reflect.Method.invoke(Method.java:498)
> \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at org.jboss.as.appclient.service.ApplicationClientStartService$1.run(ApplicationClientStartService.java:99)
> \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at java.lang.Thread.run(Thread.java:748)
> \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) Suppressed: org.jboss.remoting3.ServiceOpenException: Unknown service name jboss.ejb
> \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:440)
> \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:49)
> \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> \u001b[0m\u001b[0m22:18:25,086 INFO [stdout] (Thread-186) at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> \u001b[0m\u001b[0m22:18:25,087 INFO [stdout] (Thread-186) at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> \u001b[0m\u001b[0m22:18:25,087 INFO [stdout] (Thread-186) at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> \u001b[0m\u001b[0m22:18:25,087 INFO [stdout] (Thread-186)
> \u001b[0m\u001b[31m22:18:26,087 ERROR [stderr] (Thread-186) STATUS:Failed.Test run in ejb vehicle failed
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months