August 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13812) RemoteNamingAdd should use a capability to access the remoting Endpoint

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13812: --------------------------------------- Summary: RemoteNamingAdd should use a capability to access the remoting Endpoint Key: WFLY-13812 URL: https://issues.redhat.com/browse/WFLY-13812 Project: WildFly Issue Type: Bug Components: Naming Reporter: Brian Stansberry Assignee: Brian Stansberry RemoteNamingAdd itself provides a capability, and the remoting Endpoint is exposed by a capability, but RemoteNamingAdd is not using the capability to get the endpoint. This results in an unnecessary dependency on the org.jboss.as.remoting module. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5107) Provide equivalent to RemotingConnectorInfo via org.jboss.as.network module; expose it via "org.wildfly.remoting.connector"

by Brian Stansberry (Jira)

Brian Stansberry created WFCORE-5107: ---------------------------------------- Summary: Provide equivalent to RemotingConnectorInfo via org.jboss.as.network module; expose it via "org.wildfly.remoting.connector" Key: WFCORE-5107 URL: https://issues.redhat.com/browse/WFCORE-5107 Project: WildFly Core Issue Type: Enhancement Components: Remoting Reporter: Brian Stansberry Assignee: Brian Stansberry Get rid of the need for other subsystems to use RemotingConnectorBindingInfoService / RemotingConnectorInfo. RemotingConnectorInfo is a trivial data object, the equivalent of which could be a type in the org.jboss.as.network module. RemotingConnectorBindingInfoService is fine; it just exposes the data object, but the existing "org.wildfly.remoting.connector" should expose the new type and any public service name from RemotingConnectorBindingInfoService should be deprecated. For compatibility RemotingConnectorInfo can wrap the new type and RemotingConnectorBindingInfoService can take a consumer for both the new type and RemotingConnectorInfo. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13811) The org.jboss.as.ejb3 module dependency on org.jboss.as.remoting is not optional

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13811: --------------------------------------- Summary: The org.jboss.as.ejb3 module dependency on org.jboss.as.remoting is not optional Key: WFLY-13811 URL: https://issues.redhat.com/browse/WFLY-13811 Project: WildFly Issue Type: Bug Components: EJB Reporter: Brian Stansberry Assignee: Brian Stansberry The WFLY-13423 changes weren't enough to make EJB3's dep on org.jboss.as.remoting optional as AssociationService/AssociationImpl are installed from the subsystem root and use RemotingConnectorBindingInfoService/RemotingConnectorInfo. I'll file other JIRAs to make it possible to cut this connection, but for now the dep should not be optional. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13810) Intermittent failure in ExternalizerTestCase

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13810: --------------------------------------- Summary: Intermittent failure in ExternalizerTestCase Key: WFLY-13810 URL: https://issues.redhat.com/browse/WFLY-13810 Project: WildFly Issue Type: Bug Components: Clustering Reporter: Brian Stansberry Assignee: Paul Ferraro -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13772) Upgrade Netty to 4.1.51.Final

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13772?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13772: ------------------------------------ Fix Version/s: 21.0.0.Beta1 > Upgrade Netty to 4.1.51.Final > ----------------------------- > > Key: WFLY-13772 > URL: https://issues.redhat.com/browse/WFLY-13772 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering, JMS > Reporter: odidev PS > Assignee: Emmanuel Hugonnet > Priority: Major > Fix For: 21.0.0.Beta1 > > > Upgrade Netty to its latest version 4.1.51.Final which includes both security fixes and AArch64 performance improvements. > Refer release notes for detail: > * [https://netty.io/news/2020/05/13/4-1-50-Final.html] > * [https://netty.io/news/2020/07/09/4-1-51-Final.html] -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5106) Add configuration option in Elytron subsystem to change file encoding in FileAuditEndpoint.

by Ilia Vassilev (Jira)

Ilia Vassilev created WFCORE-5106: ------------------------------------- Summary: Add configuration option in Elytron subsystem to change file encoding in FileAuditEndpoint. Key: WFCORE-5106 URL: https://issues.redhat.com/browse/WFCORE-5106 Project: WildFly Core Issue Type: Enhancement Components: Security Reporter: Ilia Vassilev Assignee: Ilia Vassilev Add configuration option in Elytron subsystem to change file encoding in FileAuditEndpoint introduced by ELY-1211. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13809) Get application name from BatchEnvironment instead of jndi lookup

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13809?page=com.atlassian.jira.plugi... ] Cheng Fang updated WFLY-13809: ------------------------------ Description: AbstractJobOperator currently gets application name via jndi lookup. It is an expensive operation for this task. Also in non-EE environment, lookup of application name will always return null. So it is better to retrieve application name from {{BatchEnvironment}}, and different impl of {{BatchEnvironment}} can provide application name differently. Need to adjust {{BatchEnvironmentService}} to provide application name. was:AbstractJobOperator currently gets application name via jndi lookup. It is an expensive operation for this task. Also in non-EE environment, lookup of application name will always return null. So it is better to retrieve application name from {{BatchEnvironment}}, and different impl of {{BatchEnvironment}} can provide application name differently. > Get application name from BatchEnvironment instead of jndi lookup > ----------------------------------------------------------------- > > Key: WFLY-13809 > URL: https://issues.redhat.com/browse/WFLY-13809 > Project: WildFly > Issue Type: Enhancement > Components: Batch > Affects Versions: 20.0.1.Final > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > > AbstractJobOperator currently gets application name via jndi lookup. It is an expensive operation for this task. Also in non-EE environment, lookup of application name will always return null. So it is better to retrieve application name from {{BatchEnvironment}}, and different impl of {{BatchEnvironment}} can provide application name differently. > Need to adjust {{BatchEnvironmentService}} to provide application name. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13809) Get application name from BatchEnvironment instead of jndi lookup

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13809?page=com.atlassian.jira.plugi... ] Cheng Fang moved JBERET-496 to WFLY-13809: ------------------------------------------ Project: WildFly (was: JBeret) Key: WFLY-13809 (was: JBERET-496) Component/s: Batch (was: jberet-core) Affects Version/s: 20.0.1.Final (was: 1.4.0.Alpha1) Fix Version/s: (was: 1.4.0.Final) > Get application name from BatchEnvironment instead of jndi lookup > ----------------------------------------------------------------- > > Key: WFLY-13809 > URL: https://issues.redhat.com/browse/WFLY-13809 > Project: WildFly > Issue Type: Enhancement > Components: Batch > Affects Versions: 20.0.1.Final > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > > AbstractJobOperator currently gets application name via jndi lookup. It is an expensive operation for this task. Also in non-EE environment, lookup of application name will always return null. So it is better to retrieve application name from {{BatchEnvironment}}, and different impl of {{BatchEnvironment}} can provide application name differently. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined now

by Jan Stourac (Jira)

[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ] Jan Stourac updated WFWIP-339: ------------------------------ Steps to Reproduce: # build server from relevant sources based on the work of EAP7-1414: {code} https://github.com/wildfly-security/wildfly-openssl-natives/pull/1 https://github.com/wildfly-security/wildfly-openssl/pull/81 https://github.com/undertow-io/undertow/commit/818bfe3979cf9001660ee50718... (current master) https://github.com/wildfly/wildfly-core/commit/346e1b30e1f58ec1fe5805eb2c... (current master) https://github.com/wildfly/wildfly/commits/master (current master) {code} # copy `server.jks`, `client.jks` and `standalone-full.xml` files into the `EAP_HOME/standalone/configuration` directory # start server {code:java} ./bin/standalone.sh -c standalone-full.xml {code} # see relevant `WFOPENSSL0002` message is present during the server boot was: # unzip server # copy `server.jks`, `client.jks` and `standalone-full.xml` files into the `EAP_HOME/standalone/configuration` directory # start server {code:java} ./bin/standalone.sh -c standalone-full.xml {code} # see relevant `WFOPENSSL0002` message is present during the server boot > OpenSSL security provider seems to be used when not defined now > --------------------------------------------------------------- > > Key: WFWIP-339 > URL: https://issues.redhat.com/browse/WFWIP-339 > Project: WildFly WIP > Issue Type: Bug > Components: Security > Reporter: Jan Stourac > Assignee: Farah Juma > Priority: Major > Attachments: client.jks, server.jks, standalone-full.xml > > > It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior. > Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.: > {quote} > 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016 > {quote} > There are two questions from this: > # Is this change of OpenSSL provider being initialized during the boot in this configuration case expected? > # I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE. > Hope I don't have any misconfiguration in the configuration itself. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined now

by Jan Stourac (Jira)

[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ] Jan Stourac updated WFWIP-339: ------------------------------ Description: It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior. Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.: {quote} 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016 {quote} There are two questions from this: # Is this change of OpenSSL provider being initialized during the boot in this configuration case expected? # I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE. Hope I don't have any misconfiguration in the configuration itself. was: It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior. Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.: {quote} 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016 {quote} > OpenSSL security provider seems to be used when not defined now > --------------------------------------------------------------- > > Key: WFWIP-339 > URL: https://issues.redhat.com/browse/WFWIP-339 > Project: WildFly WIP > Issue Type: Bug > Components: Security > Reporter: Jan Stourac > Assignee: Farah Juma > Priority: Major > Attachments: client.jks, server.jks, standalone-full.xml > > > It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior. > Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.: > {quote} > 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016 > {quote} > There are two questions from this: > # Is this change of OpenSSL provider being initialized during the boot in this configuration case expected? > # I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE. > Hope I don't have any misconfiguration in the configuration itself. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2020