[JBoss JIRA] (WFLY-13723) Many Jakarta EE 8 TCK tests are failing due to "Unknown service name jboss.ejb"
by Scott Marlow (Jira)
Scott Marlow created WFLY-13723:
-----------------------------------
Summary: 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
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
[JBoss JIRA] (AG-143) Add s flush mode to forcefully remove leaked connections
by Luis Barreiro (Jira)
[ https://issues.redhat.com/browse/AG-143?page=com.atlassian.jira.plugin.sy... ]
Luis Barreiro resolved AG-143.
------------------------------
Resolution: Done
> Add s flush mode to forcefully remove leaked connections
> --------------------------------------------------------
>
> Key: AG-143
> URL: https://issues.redhat.com/browse/AG-143
> Project: Agroal
> Issue Type: Bug
> Components: api, pool
> Affects Versions: 1.8
> Reporter: Luis Barreiro
> Assignee: Luis Barreiro
> Priority: Major
> Fix For: 1.9
>
>
> When there is a notification of a leaking connection there is no way to remove that connection from the pool. In the event of uncommon connection leaks, these will accumulate over time, eventually blocking the pool. Using the existing mechanism for flush operations, add a new mode to allow the removal of these connections.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-13722) When using Galleon to provision Wildfly with core-server+managment layers, the availability of the Admin console is wrongly advertised to the user
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13722?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFLY-13722:
-----------------------------------------
I suspect this will become a WildFly Core issue with the component "Management"! - although Galleon may be the reproducer the message is from management related modules.
> When using Galleon to provision Wildfly with core-server+managment layers, the availability of the Admin console is wrongly advertised to the user
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13722
> URL: https://issues.redhat.com/browse/WFLY-13722
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Affects Versions: 20.0.0.Final
> 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] (AG-146) Rename housekeeping threads
by Luis Barreiro (Jira)
Luis Barreiro created AG-146:
--------------------------------
Summary: Rename housekeeping threads
Key: AG-146
URL: https://issues.redhat.com/browse/AG-146
Project: Agroal
Issue Type: Bug
Components: pool
Affects Versions: 1.8
Reporter: Luis Barreiro
Assignee: Luis Barreiro
Fix For: 1.9
Rename housekeeping threads to `agroal-x` to align with names usually used in thread pools.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-13697) JBoss CLI can't find java:app/AppName
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13697?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-13697:
-----------------------------------
I linked 2 similar issues. The general idea is to switch the deployment's naming context for this batch operation, and then reset it afterwards, but we haven't figured out the details yet.
> JBoss CLI can't find java:app/AppName
> -------------------------------------
>
> Key: WFLY-13697
> URL: https://issues.redhat.com/browse/WFLY-13697
> Project: WildFly
> Issue Type: Bug
> Components: Batch, Management
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: José Fernando Tepedino Martins
> Assignee: Michal Petrov
> Priority: Minor
> Labels: CLI, JNDI
>
> With a JEE aplication in a WAR package, when starting a functionality, as a Batch Job, via CLI, CDI injection and JNDI lookup fail to find resources 'java:app/AppName' and 'java:module/ModuleName'.
> For example, a job listener or other job artifact with the following code
> {code:java}
> @Resource(lookup="java:app/AppName")
> private String applicationName;{code}
> or
> {code:java}
> private String applicationName;
> @PostConstruct
> protected void initialize() throws NamingException {
> applicationName = InitialContext.doLookup("java:app/AppName");
> }{code}
> when the batch job is started from JBoss CLI, the following error will be logged:
> {code:java}
> javax.naming.NameNotFoundException: java:app/AppName
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[JBoss JIRA] (WFLY-13722) 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)
Fabio Burzigotti created WFLY-13722:
---------------------------------------
Summary: When using Galleon to provision Wildfly with core-server+managment layers, the availability of the Admin console is wrongly advertised to the user
Key: WFLY-13722
URL: https://issues.redhat.com/browse/WFLY-13722
Project: WildFly
Issue Type: Bug
Components: Build System
Affects Versions: 20.0.0.Final
Reporter: Fabio Burzigotti
Assignee: Brian Stansberry
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-13676) Increase the test coverage of jpa and jpa-distributed galleon layers
by Yeray Borges Santana (Jira)
[ https://issues.redhat.com/browse/WFLY-13676?page=com.atlassian.jira.plugi... ]
Yeray Borges Santana reopened WFLY-13676:
-----------------------------------------
> Increase the test coverage of jpa and jpa-distributed galleon layers
> --------------------------------------------------------------------
>
> Key: WFLY-13676
> URL: https://issues.redhat.com/browse/WFLY-13676
> Project: WildFly
> Issue Type: Task
> Components: Build System, JPA / Hibernate, Test Suite
> Reporter: Yeray Borges Santana
> Assignee: Yeray Borges Santana
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> These layers must be tested independently on testsuite/layers testsuite.
> These layers should also be tested in aggregation with one or more base layers it is expected to decorate, running the test with each of one separately.
> We have to add new Galleon provision execution to provision a server with a base layer provisioned with jpa or jpa-distributed and add a surefire execution to run suitable WildFly tests on them.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months