[JBoss JIRA] (WFCORE-5116) Bootable JAR, JMX not properly initialized at boot.
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFCORE-5116?page=com.atlassian.jira.plug... ]
Jean Francois Denise updated WFCORE-5116:
-----------------------------------------
Description:
The correct MBeanServer builder must be set for the server's MBeans to be registered in the PlatformMBeanServer.
Furthermore, JBoss Modules MBeans must be registered.
was:The correct MBeanServer builder must be set for the server's MBeans to be registered in the PlatformMBeanServer.
> Bootable JAR, JMX not properly initialized at boot.
> ---------------------------------------------------
>
> Key: WFCORE-5116
> URL: https://issues.redhat.com/browse/WFCORE-5116
> Project: WildFly Core
> Issue Type: Bug
> Components: Bootable JAR
> Reporter: Jean Francois Denise
> Assignee: Jean Francois Denise
> Priority: Major
>
> The correct MBeanServer builder must be set for the server's MBeans to be registered in the PlatformMBeanServer.
> Furthermore, JBoss Modules MBeans must be registered.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined with JDK8 now
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ]
Farah Juma edited comment on WFWIP-339 at 9/2/20 4:16 PM:
----------------------------------------------------------
[~jstourac] Was able to reproduce with 1.8.0_241. Because support for TLS 1.3 was backported to 1.8.0_261, when going through the {{providerList}} to return a best match in [SSLUtils#createSSLContextFactory|https://github.com/wildfly-security/wild...], the JDK TLS 1.3 provider will be used and no message will appear in the server log. With 1.8.0_241, the JDK TLS 1.3 provider isn't present and so the OpenSSL TLS 1.3 provider will be attempted resulting in the OpenSSL version appearing in the logs. Since we actually only want to support TLS 1.3 with JDK 11 or higher, I've updated {{OpenSSLProvider}} to add appropriate {{getJavaSpecVersion}} checks and I've pushed this change to my wildfly-openssl branch. I've verified that the message now no longer appears in the log with both JDK 8 versions and with JDK 11 unless we specify that the OpenSSL provider should be used.
was (Author: fjuma):
[~jstourac] Was able to reproduce with 1.8.0_241. Because support for TLS 1.3 was backported to 1.8.0_261, when going through the {{providerList}} to return a best match in [SSLUtils#createSSLContextFactory|https://github.com/wildfly-security/wild...], the JDK TLS 1.3 provider will be used and no message will appear in the server log. With 1.8.0_241, the JDK TLS 1.3 provider isn't present and so the OpenSSL TLS 1.3 provider will be attempted resulting in the OpenSSL version appearing in the logs. Since we actually only want to support TLS 1.3 with JDK 11 or higher, I've updated {{OpenSSLProvider}} to add appropriate {{getJavaSpecVersion}} checks and I've pushed this change to my wildfly-openssl branch.
> OpenSSL security provider seems to be used when not defined with JDK8 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. I also see this change of behavior only with JDK8. JDK11 works as expected!
> 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}
> This INFO message starts to occur in the server log since 'server-ssl-context' or 'client-ssl-contexts' are added into the server configuration and server is started with JDK8:
> {code}
> <server-ssl-contexts>
> <server-ssl-context name="server-ssl-context" need-client-auth="true" key-manager="server-ssl-contextKM" trust-manager="server-ssl-contextTM"/>
> </server-ssl-contexts>
> <client-ssl-contexts>
> <client-ssl-context name="proxy-ssl-context" key-manager="proxy-ssl-contextKM" trust-manager="proxy-ssl-contextTM"/>
> </client-ssl-contexts>
> {code}
> 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. Not to mention that we don't want to behave differently for JDK8 and JDK11.
> Hope I don't have any misconfiguration in the configuration itself.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined with JDK8 now
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ]
Farah Juma commented on WFWIP-339:
----------------------------------
[~jstourac] Was able to reproduce with 1.8.0_241. Because support for TLS 1.3 was backported to 1.8.0_261, when going through the {{providerList}} to return a best match in [SSLUtils#createSSLContextFactory|https://github.com/wildfly-security/wild...], the JDK TLS 1.3 provider will be used and no message will appear in the server log. With 1.8.0_241, the JDK TLS 1.3 provider isn't present and so the OpenSSL TLS 1.3 provider will be attempted resulting in the OpenSSL version appearing in the logs. Since we actually only want to support TLS 1.3 with JDK 11 or higher, I've updated {{OpenSSLProvider}} to add appropriate {{getJavaSpecVersion}} checks and I've pushed this change to my wildfly-openssl branch.
> OpenSSL security provider seems to be used when not defined with JDK8 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. I also see this change of behavior only with JDK8. JDK11 works as expected!
> 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}
> This INFO message starts to occur in the server log since 'server-ssl-context' or 'client-ssl-contexts' are added into the server configuration and server is started with JDK8:
> {code}
> <server-ssl-contexts>
> <server-ssl-context name="server-ssl-context" need-client-auth="true" key-manager="server-ssl-contextKM" trust-manager="server-ssl-contextTM"/>
> </server-ssl-contexts>
> <client-ssl-contexts>
> <client-ssl-context name="proxy-ssl-context" key-manager="proxy-ssl-contextKM" trust-manager="proxy-ssl-contextTM"/>
> </client-ssl-contexts>
> {code}
> 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. Not to mention that we don't want to behave differently for JDK8 and JDK11.
> Hope I don't have any misconfiguration in the configuration itself.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFCORE-5115) Allow a properties file which contains system properties to be loaded in the bootable JAR's entry point
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-5115?page=com.atlassian.jira.plug... ]
James Perkins updated WFCORE-5115:
----------------------------------
Description: With the fix for [generating a {{logging.properties}} config|https://github.com/wildfly-extras/wildfly-jar-maven-plugin/issues/73] there is a chance properties defined in the {{system-properties}} or {{path}} resource may be needed for the log manager at boot. As part of the mentioned fix a {{boot-config.properties}} file will be generated. The entry point of the bootable JAR should look for this file in the {{$JBOSS_HOME/standalone/configuration}} directory and if found load those system properties before the log manager is configured. (was: With the fix for [generating a {{logging.properties}} config|https://github.com/wildfly-extras/wildfly-jar-maven-plugin/issues/73] there is a chance properties defined in the {{system-properties}} or {{path}} resource may be needed for the log manager at boot. As part of the mentioned fix a {{boot-config.properties}} file will be generated. The entry point of the bootable JAR should look for this file in the {{$JBOSS_HOME/standalone/configuration}} directory and if found load those system properties before the log manager is configured. Properties passed to via the command line should take precedence over these defined properties as well.)
> Allow a properties file which contains system properties to be loaded in the bootable JAR's entry point
> -------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-5115
> URL: https://issues.redhat.com/browse/WFCORE-5115
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Bootable JAR
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
>
> With the fix for [generating a {{logging.properties}} config|https://github.com/wildfly-extras/wildfly-jar-maven-plugin/issues/73] there is a chance properties defined in the {{system-properties}} or {{path}} resource may be needed for the log manager at boot. As part of the mentioned fix a {{boot-config.properties}} file will be generated. The entry point of the bootable JAR should look for this file in the {{$JBOSS_HOME/standalone/configuration}} directory and if found load those system properties before the log manager is configured.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFLY-13679) Make legacy security optional for "org.wildfly.iiop-openjdk"
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13679?page=com.atlassian.jira.plugi... ]
Cheng Fang updated WFLY-13679:
------------------------------
Description:
The dependency needs to optional so provisioning a layer with iiop-openjdk does not automatically pull in legacy security.
This is not just about making the module dependency optional, this is about understanding why it is not optional and identifying the steps required to make it optional.
This needs to consider:
* Default Configuration
* User Defined Configuration
Both of these can have different consequences depending on of they are used for:
* Resource defined services
* DeploymentUnitProcessor processing
iiop-openjdk module.xml: https://github.com/wildfly/wildfly/blob/master/ee-feature-pack/common/src...
was:
The dependency needs to optional so provisioning a layer with iiop-openjdk does not automatically pull in legacy security.
This is not just about making the module dependency optional, this is about understanding why it is not optional and identifying the steps required to make it optional.
This needs to consider:
* Default Configuration
* User Defined Configuration
Both of these can have different consequences depending on of they are used for:
* Resource defined services
* DeploymentUnitProcessor processing
> Make legacy security optional for "org.wildfly.iiop-openjdk"
> ------------------------------------------------------------
>
> Key: WFLY-13679
> URL: https://issues.redhat.com/browse/WFLY-13679
> Project: WildFly
> Issue Type: Sub-task
> Components: IIOP, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> The dependency needs to optional so provisioning a layer with iiop-openjdk does not automatically pull in legacy security.
> This is not just about making the module dependency optional, this is about understanding why it is not optional and identifying the steps required to make it optional.
> This needs to consider:
> * Default Configuration
> * User Defined Configuration
> Both of these can have different consequences depending on of they are used for:
> * Resource defined services
> * DeploymentUnitProcessor processing
> iiop-openjdk module.xml: https://github.com/wildfly/wildfly/blob/master/ee-feature-pack/common/src...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFCORE-5116) Bootable JAR, JMX not properly initialized at boot.
by Jean Francois Denise (Jira)
Jean Francois Denise created WFCORE-5116:
--------------------------------------------
Summary: Bootable JAR, JMX not properly initialized at boot.
Key: WFCORE-5116
URL: https://issues.redhat.com/browse/WFCORE-5116
Project: WildFly Core
Issue Type: Bug
Components: Bootable JAR
Reporter: Jean Francois Denise
Assignee: Jean Francois Denise
The correct MBeanServer builder must be set for the server's MBeans to be registered in the PlatformMBeanServer.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFLY-13679) Make legacy security optional for "org.wildfly.iiop-openjdk"
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13679?page=com.atlassian.jira.plugi... ]
Cheng Fang updated WFLY-13679:
------------------------------
Description:
The dependency needs to optional so provisioning a layer with iiop-openjdk does not automatically pull in legacy security.
This is not just about making the module dependency optional, this is about understanding why it is not optional and identifying the steps required to make it optional.
This needs to consider:
* Default Configuration
* User Defined Configuration
Both of these can have different consequences depending on of they are used for:
* Resource defined services
* DeploymentUnitProcessor processing
was:
The dependency needs to optional so provisioning a layer with batch does not automatically pull in legacy security.
This is not just about making the module dependency optional, this is about understanding why it is not optional and identifying the steps required to make it optional.
This needs to consider:
* Default Configuration
* User Defined Configuration
Both of these can have different consequences depending on of they are used for:
* Resource defined services
* DeploymentUnitProcessor processing
> Make legacy security optional for "org.wildfly.iiop-openjdk"
> ------------------------------------------------------------
>
> Key: WFLY-13679
> URL: https://issues.redhat.com/browse/WFLY-13679
> Project: WildFly
> Issue Type: Sub-task
> Components: IIOP, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> The dependency needs to optional so provisioning a layer with iiop-openjdk does not automatically pull in legacy security.
> This is not just about making the module dependency optional, this is about understanding why it is not optional and identifying the steps required to make it optional.
> This needs to consider:
> * Default Configuration
> * User Defined Configuration
> Both of these can have different consequences depending on of they are used for:
> * Resource defined services
> * DeploymentUnitProcessor processing
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFLY-13820) Make the annoying jaeger 'shutdown hook' logging go away
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-13820:
---------------------------------------
Summary: Make the annoying jaeger 'shutdown hook' logging go away
Key: WFLY-13820
URL: https://issues.redhat.com/browse/WFLY-13820
Project: WildFly
Issue Type: Enhancement
Components: MP OpenTracing
Reporter: Brian Stansberry
Assignee: Emmanuel Hugonnet
If there's something simple that can be done to make this go away it would be nice.
{code}
INFO [io.jaegertracing.internal.JaegerTracer] (MSC service thread 1-4) No shutdown hook registered: Please call close() manually on application shutdown.
INFO [io.jaegertracing.internal.JaegerTracer] (MSC service thread 1-2) No shutdown hook registered: Please call close() manually on application shutdown.
{code}
I'm not looking for anything nasty or complex here; feel free to reject this if something like that is needed.
Of course if what's it's asking for is something we should be doing but aren't, then this is a bug. :) But I assume whatever it would want done via a shutdown hook is not something an appserver that supports 'reload' would use a shutdown hook to accomplish.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months