August 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-5079) The management layer should make it more obvious it is unsecured

by Darran Lofthouse (Jira)

Darran Lofthouse created WFCORE-5079: ---------------------------------------- Summary: The management layer should make it more obvious it is unsecured Key: WFCORE-5079 URL: https://issues.redhat.com/browse/WFCORE-5079 Project: WildFly Core Issue Type: Task Components: Build System, Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 13.0.0.Beta4 At the moment it is only in the documentation that it is unsecured, a list of layers could be created similar to: {code:xml} <configs> <config> <name>standalone.xml</name> <model>standalone</model> <layers> <layer>management</layer> <layer>remoting</layer> <layer>elytron</layer> <layer>web-server</layer> </layers> </config> {code} >From a code review of a snippet like this unless the documentation is cross referenced nothing looks out of place, if instead management was renamed unsecured-management it would be obvious in a review. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2493) RELAY does not use protocol stack supplied programmatically

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2493?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2493: -------------------------------- You have to differentiate between {{channel}}, which is the channel for the local cluster (and which can be set using {{setProtocolStack()}}), and {{bridge}} which is the channel for the bridge cluster. The latter cannot currently be set, other than passing correct {{bridge_props}} to {{RELAY}}. I suggest you create a subclass of {{RELAY}} and override {{createBridge()}} to create your bridge channel programmatically. I'll also create a getter/setter to a function which creates the bridge channel. > RELAY does not use protocol stack supplied programmatically > ----------------------------------------------------------- > > Key: JGRP-2493 > URL: https://issues.redhat.com/browse/JGRP-2493 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.2.4 > Reporter: S Pokutniy > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.5 > > > RELAY does not use protocol stack supplied programmatically (i.e. stack which was set by using relay.setProtocolStack(protocolStack). Even though the stack is used in init(), the function below only relies on bridge_props file. Even though using an XML file is mostly possible, it becomes problematic when a custom SSLContext needs to be used in SSL_KEY_EXCHANGE, which can now only be set programmatically. > > protected void createBridge() { > try { > if(log.isTraceEnabled()) > log.trace("I'm the coordinator, creating a channel (props=" + bridge_props + ", cluster_name=" + bridge_name + ")"); > {color:#FF0000}bridge=new JChannel(bridge_props);{color} > bridge.setDiscardOwnMessages(true); // don't receive my own messages > bridge.setReceiver(new Receiver()); > bridge.connect(bridge_name); > } > catch(Exception e) { > log.error(Util.getMessage("FailedCreatingBridgeChannelProps") + bridge_props + ")", e); > } > } -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2493) RELAY does not use protocol stack supplied programmatically

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2493?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2493: --------------------------- Workaround Description: Changed to 4.2.5: 5.0.0 has no RELAY any longer (deprecated) Fix Version/s: 4.2.5 (was: 5.0.0.Final) > RELAY does not use protocol stack supplied programmatically > ----------------------------------------------------------- > > Key: JGRP-2493 > URL: https://issues.redhat.com/browse/JGRP-2493 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.2.4 > Reporter: S Pokutniy > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.5 > > > RELAY does not use protocol stack supplied programmatically (i.e. stack which was set by using relay.setProtocolStack(protocolStack). Even though the stack is used in init(), the function below only relies on bridge_props file. Even though using an XML file is mostly possible, it becomes problematic when a custom SSLContext needs to be used in SSL_KEY_EXCHANGE, which can now only be set programmatically. > > protected void createBridge() { > try { > if(log.isTraceEnabled()) > log.trace("I'm the coordinator, creating a channel (props=" + bridge_props + ", cluster_name=" + bridge_name + ")"); > {color:#FF0000}bridge=new JChannel(bridge_props);{color} > bridge.setDiscardOwnMessages(true); // don't receive my own messages > bridge.setReceiver(new Receiver()); > bridge.connect(bridge_name); > } > catch(Exception e) { > log.error(Util.getMessage("FailedCreatingBridgeChannelProps") + bridge_props + ")", e); > } > } -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[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: ------------------------------------- The Jakarta EE 8 Platform TCK run against rachmatowicz:WFLY-13723 passed last night, which verifies that the fix does correct [WFLY-13723] Thanks [~cfang] Thanks [~rachmato]! > 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, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1199) Traces tab into Applications

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1199: ------------------------------------- Summary: Traces tab into Applications Key: SWSQE-1199 URL: https://issues.redhat.com/browse/SWSQE-1199 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5060) AS-TS IBM test cases fails due to update mockserver-netty

by Vratislav Marek (Jira)

[ https://issues.redhat.com/browse/WFCORE-5060?page=com.atlassian.jira.plug... ] Vratislav Marek closed WFCORE-5060. ----------------------------------- Resolution: Duplicate Issue Duplicate, closing. > AS-TS IBM test cases fails due to update mockserver-netty > --------------------------------------------------------- > > Key: WFCORE-5060 > URL: https://issues.redhat.com/browse/WFCORE-5060 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 11.0.0.Final, 12.0.3.Final, 13.0.0.Beta2 > Reporter: Vratislav Marek > Priority: Major > > Affected test Cases > * org.wildfly.extension.elytron.CertificateAuthoritiesTestCase > * org.wildfly.extension.elytron.KeyStoresTestCase > * org.jboss.as.test.integration.management.cli.SecurityCommandsTestCase > It failed after: > * [wildfly/wildfly-core: Pull Request 4085|https://github.com/wildfly/wildfly-core/pull/4085] > * update mockserver-client-java/core/netty from 5.4.1 to 5.9.0 > Root cause: > * java.lang.NoClassDefFoundError: sun.security.x509.GeneralNameInterface > Environments: > * IBM jdk 1.8 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1410) Oracle UCP support: notify OracleConnection about begin and end of the requestion

by Tomasz Adamski (Jira)

Tomasz Adamski created JBJCA-1410: ------------------------------------- Summary: Oracle UCP support: notify OracleConnection about begin and end of the requestion Key: JBJCA-1410 URL: https://issues.redhat.com/browse/JBJCA-1410 Project: IronJacamar Issue Type: Feature Request Reporter: Tomasz Adamski Assignee: Tomasz Adamski -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13740) Upgrade Narayana to 5.10.6.Final

by Bartosz Spyrko-Smietanko (Jira)

[ https://issues.redhat.com/browse/WFLY-13740?page=com.atlassian.jira.plugi... ] Bartosz Spyrko-Smietanko updated WFLY-13740: -------------------------------------------- Description: Component upgrade of Narayana to version 5.10.6.Final. This is to track fix for JBTM-3337 in Wildfly required by downstream was: Component upgrade of Narayana to version 5.10.5.Final. This version provides the capability for CDI interceptors of context propagation and async handling. > Upgrade Narayana to 5.10.6.Final > -------------------------------- > > Key: WFLY-13740 > URL: https://issues.redhat.com/browse/WFLY-13740 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Reporter: Bartosz Spyrko-Smietanko > Assignee: Ondrej Chaloupka > Priority: Major > Labels: downstream_dependency > > Component upgrade of Narayana to version 5.10.6.Final. > This is to track fix for JBTM-3337 in Wildfly required by downstream -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13740) Upgrade Narayana to 5.10.6.Final

by Bartosz Spyrko-Smietanko (Jira)

[ https://issues.redhat.com/browse/WFLY-13740?page=com.atlassian.jira.plugi... ] Bartosz Spyrko-Smietanko updated WFLY-13740: -------------------------------------------- Labels: downstream_dependency (was: ) > Upgrade Narayana to 5.10.6.Final > -------------------------------- > > Key: WFLY-13740 > URL: https://issues.redhat.com/browse/WFLY-13740 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Reporter: Bartosz Spyrko-Smietanko > Assignee: Ondrej Chaloupka > Priority: Major > Labels: downstream_dependency > > Component upgrade of Narayana to version 5.10.5.Final. > This version provides the capability for CDI interceptors of context propagation and async handling. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13740) Upgrade Narayana to 5.10.6.Final

by Bartosz Spyrko-Smietanko (Jira)

[ https://issues.redhat.com/browse/WFLY-13740?page=com.atlassian.jira.plugi... ] Bartosz Spyrko-Smietanko updated WFLY-13740: -------------------------------------------- Fix Version/s: (was: 20.0.0.Beta1) (was: 20.0.0.Final) > Upgrade Narayana to 5.10.6.Final > -------------------------------- > > Key: WFLY-13740 > URL: https://issues.redhat.com/browse/WFLY-13740 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Reporter: Bartosz Spyrko-Smietanko > Assignee: Ondrej Chaloupka > Priority: Major > > Component upgrade of Narayana to version 5.10.5.Final. > This version provides the capability for CDI interceptors of context propagation and async handling. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2020