[JBoss JIRA] (DROOLS-5617) Refacto MiningModel source generation
by Gabriele Cardosi (Jira)
Gabriele Cardosi created DROOLS-5617:
----------------------------------------
Summary: Refacto MiningModel source generation
Key: DROOLS-5617
URL: https://issues.redhat.com/browse/DROOLS-5617
Project: Drools
Issue Type: Task
Reporter: Gabriele Cardosi
Assignee: Gabriele Cardosi
For code generation, currently, all sources of segment models of a MiningModel are put in the main (container) model sourcemap, and the list of "nested models" is empty.
Scope of this refactor is to populate the list of nested models with the "HasSourcesMap" version of all the models, and populate the "main" sourcemap only with the MiningModel specific sources
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month
[JBoss JIRA] (DROOLS-5616) Be able to set with an Env Variable that KIE using XStream does not complain on unknown fields
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5616?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi moved RHDM-1446 to DROOLS-5616:
-------------------------------------------------
Project: Drools (was: Red Hat Decision Manager)
Key: DROOLS-5616 (was: RHDM-1446)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Docs QE Status: NEW
Component/s: kie server
(was: Kie-Server)
Environment: (was: In our project "Migration Analytics" we have our integration (camel) app sending requests to the KIE Server. Everything deployed on Openshift.
Sometimes the integration app evolves adding new fields to the pojos being sent to KIE, but now we need to wait for the changes done on the project deployed in KIE to be able to merge the first PR on the integration.
I know XStream has a method called ".ignoreUnknownElements()" so the proposal would be to have an environment variable that KIE would read and execute that method just after creating the unmarshaller.)
QE Status: NEW
> Be able to set with an Env Variable that KIE using XStream does not complain on unknown fields
> ----------------------------------------------------------------------------------------------
>
> Key: DROOLS-5616
> URL: https://issues.redhat.com/browse/DROOLS-5616
> Project: Drools
> Issue Type: Feature Request
> Components: kie server
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month
[JBoss JIRA] (WFLY-13821) Add a Galleon layer for the distributable web subsystem configured with a local web cache
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-13821:
---------------------------------------
Summary: Add a Galleon layer for the distributable web subsystem configured with a local web cache
Key: WFLY-13821
URL: https://issues.redhat.com/browse/WFLY-13821
Project: WildFly
Issue Type: Feature Request
Components: Clustering, Web (Undertow)
Reporter: Brian Stansberry
Assignee: Yeray Borges Santana
Fix For: 21.0.0.Beta1
We have a web-clustering layer that provides the distributable-web subsystem and the related infinispan web session caching resources, configured for multi-server distributed sessions.
We need a variant of this with infinispan configured for local caching.
The WFLY-13099 standalone-microprofile.xml config should have this kind of setup; otherwise session sharing does not work . (A failure in org.jboss.as.test.clustering.cluster.web.shared.SharedSessionTestCase if the server uses a config without it shows this.) For WFLY-13099 I can work around this by adding the needed config stuff without a layer, but as everything else needed for those configs are from layers, it's better to use a layer in WF 20.
Besides it's a good layer to have anyway. :)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 1 month
[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)
5 years, 1 month
[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)
5 years, 1 month
[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)
5 years, 1 month
[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)
5 years, 1 month
[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)
5 years, 1 month