[JBoss JIRA] (WFCORE-5077) When using Galleon to provision Wildfly with core-server+managment layers, the availability of the Admin console is wrongly advertised to the user
by Brian Stansberry (Jira)
Brian Stansberry created WFCORE-5077:
----------------------------------------
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: WFCORE-5077
URL: https://issues.redhat.com/browse/WFCORE-5077
Project: WildFly Core
Issue Type: Bug
Components: Management
Affects Versions: 12.0.2.Final, 13.0.0.Beta2
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, 1 month
[JBoss JIRA] (WFCORE-5076) remoting http-connector silently accepts invalid security-realm
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-5076?page=com.atlassian.jira.plug... ]
Darran Lofthouse moved WFLY-13724 to WFCORE-5076:
-------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-5076 (was: WFLY-13724)
Component/s: Remoting
(was: Remoting)
Fix Version/s: 13.0.0.Beta3
(was: 21.0.0.Beta1)
> remoting http-connector silently accepts invalid security-realm
> ---------------------------------------------------------------
>
> Key: WFCORE-5076
> URL: https://issues.redhat.com/browse/WFCORE-5076
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 13.0.0.Beta3
>
>
> If the remoting subsystem is changed to the following:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="OtherRealm"/>
> </subsystem>
> {code}
> The server starts without error, however attempting to establish a connection fails.
> {code}
> ./jboss-cli.sh -c --controller=remote+http://localhost:8080
> Failed to connect to the controller: The controller is not available at localhost:8080: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost:8080. The connection failed: WFLYPRT0053: Could not connect to remote+http://localhost:8080. The connection failed: Invalid response code 200
> {code}
> Although the CLI can not do anything over port 8080 it should be able to initiate a remoting connection i.e.
> {code}
> ./jboss-cli.sh -c --controller=remote+http://localhost:8080
> Failed to connect to the controller: The controller is not available at localhost:8080: org.jboss.remoting3.ServiceOpenException: Unknown service name management: Unknown service name management
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month
[JBoss JIRA] (WFLY-13724) remoting http-connector silently accepts invalid security-realm
by Darran Lofthouse (Jira)
Darran Lofthouse created WFLY-13724:
---------------------------------------
Summary: remoting http-connector silently accepts invalid security-realm
Key: WFLY-13724
URL: https://issues.redhat.com/browse/WFLY-13724
Project: WildFly
Issue Type: Bug
Components: Remoting
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 21.0.0.Beta1
If the remoting subsystem is changed to the following:
{code:xml}
<subsystem xmlns="urn:jboss:domain:remoting:4.0">
<http-connector name="http-remoting-connector" connector-ref="default" security-realm="OtherRealm"/>
</subsystem>
{code}
The server starts without error, however attempting to establish a connection fails.
{code}
./jboss-cli.sh -c --controller=remote+http://localhost:8080
Failed to connect to the controller: The controller is not available at localhost:8080: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost:8080. The connection failed: WFLYPRT0053: Could not connect to remote+http://localhost:8080. The connection failed: Invalid response code 200
{code}
Although the CLI can not do anything over port 8080 it should be able to initiate a remoting connection i.e.
{code}
./jboss-cli.sh -c --controller=remote+http://localhost:8080
Failed to connect to the controller: The controller is not available at localhost:8080: org.jboss.remoting3.ServiceOpenException: Unknown service name management: Unknown service name management
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month
[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 Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-5073?page=com.atlassian.jira.plug... ]
Brian Stansberry commented on WFCORE-5073:
------------------------------------------
The issue is the ConsoleMode is determined solely from the config settings, ignoring the actual availability of a console.
> 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, 1 month
[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 Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-5073?page=com.atlassian.jira.plug... ]
Brian Stansberry commented on WFCORE-5073:
------------------------------------------
The problem is somehow UndertowHttpManagementService.consoleMode is ending up with the enum value 'CONSOLE', which seems wrong given there is no console.
> 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, 1 month
[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 Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-5073?page=com.atlassian.jira.plug... ]
Brian Stansberry commented on WFCORE-5073:
------------------------------------------
+1 [~dlofthouse] -- I moved it. This is a general problem with WildFly Core, not particularly related to Galleon. For example, if you take the WildFly Core dist and run standalone.sh you get the 'INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990' message even though WF Core doesn't include the console.
> 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, 1 month
[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 Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-5073?page=com.atlassian.jira.plug... ]
Brian Stansberry moved WFLY-13722 to WFCORE-5073:
-------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-5073 (was: WFLY-13722)
Component/s: Management
(was: Build System)
Affects Version/s: 13.0.0.Beta2
12.0.2.Final
(was: 20.0.0.Final)
> 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: 13.0.0.Beta2, 12.0.2.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, 1 month
[JBoss JIRA] (WFLY-13723) Many Jakarta EE 8 TCK tests are failing due to "Unknown service name jboss.ejb"
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/WFLY-13723?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on WFLY-13723:
-------------------------------------
This the "Unknown service name jboss.ejb" failure may be caused by [WFLY-13433] + [https://github.com/wildfly/wildfly/pull/13415].
> 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, 1 month