[JBoss JIRA] (WFCORE-5109) Ensure the log manager configurator is attached to the root logger
by James Perkins (Jira)
James Perkins created WFCORE-5109:
-------------------------------------
Summary: Ensure the log manager configurator is attached to the root logger
Key: WFCORE-5109
URL: https://issues.redhat.com/browse/WFCORE-5109
Project: WildFly Core
Issue Type: Bug
Components: Bootable JAR, Logging
Reporter: James Perkins
Assignee: James Perkins
The entry point for the bootable JAR configures a custom log context. The logging subsystem looks on the root logger of that context to locate the {{Configurator}} which was used to configure the context. The configurator should be attached to the root logger so the subsystem locate it. Without this the context will be reconfigured resulting in possible truncation of log messages.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 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] Yes, I was using JDK 1.8.0_261. I'll try 1.8.0_241 today. Thanks!
> 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, 4 months
[JBoss JIRA] (DROOLS-5613) Disable Trusty pmml when jpmml is present
by Gabriele Cardosi (Jira)
Gabriele Cardosi created DROOLS-5613:
----------------------------------------
Summary: Disable Trusty pmml when jpmml is present
Key: DROOLS-5613
URL: https://issues.redhat.com/browse/DROOLS-5613
Project: Drools
Issue Type: Task
Reporter: Gabriele Cardosi
Assignee: Gabriele Cardosi
Inside trusty PMMLAssembler:
1. copy/refactor isjPMMLAvailableToClassLoader (from legacy PMMLAssembler)
2. modify
{code:java}
private static boolean isToEnable()
{code}
to always return "false" when jpmml is present
Inside legacy PMMLAssembler:
1. modify
{code:java}
private static boolean isToEnable()
{code}
to always return "false" when jpmml is present
2. remove isjPMMLAvailableToClassLoader invocation from
{code:java}
private void addPackage(Resource resource)
{code}
3. modify isjPMMLAvailableToClassLoader to log when jpmml is present
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFCORE-5103) Adding non existent and not required keystore fails
by Martin Mazánek (Jira)
[ https://issues.redhat.com/browse/WFCORE-5103?page=com.atlassian.jira.plug... ]
Martin Mazánek reassigned WFCORE-5103:
--------------------------------------
Assignee: Martin Mazánek (was: Darran Lofthouse)
> Adding non existent and not required keystore fails
> ---------------------------------------------------
>
> Key: WFCORE-5103
> URL: https://issues.redhat.com/browse/WFCORE-5103
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jean Francois Denise
> Assignee: Martin Mazánek
> Priority: Major
> Fix For: 13.0.0.Beta6
>
>
> We are in a case where a CLI script is executed in an embedded server. They keystore added doesn't exist locally when the script is run. The operation is:
> /subsystem=elytron/key-store=keystore:add(required=false, path="/etc/foo/keystore.jks", credential-reference=\{clear-text=${keystore.password}})
> Error:
> "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.keystore" => "WFLYELY00004: Unable to start the service.
> [ERROR] Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00022: KeyStore file '/etc/wf-secrets/keystore.jks' does not exist and required."}},
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFCORE-5103) Adding non existent and not required keystore fails
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFCORE-5103?page=com.atlassian.jira.plug... ]
Farah Juma updated WFCORE-5103:
-------------------------------
Priority: Major (was: Blocker)
> Adding non existent and not required keystore fails
> ---------------------------------------------------
>
> Key: WFCORE-5103
> URL: https://issues.redhat.com/browse/WFCORE-5103
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jean Francois Denise
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 13.0.0.Beta6
>
>
> We are in a case where a CLI script is executed in an embedded server. They keystore added doesn't exist locally when the script is run. The operation is:
> /subsystem=elytron/key-store=keystore:add(required=false, path="/etc/foo/keystore.jks", credential-reference=\{clear-text=${keystore.password}})
> Error:
> "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.keystore" => "WFLYELY00004: Unable to start the service.
> [ERROR] Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00022: KeyStore file '/etc/wf-secrets/keystore.jks' does not exist and required."}},
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFCORE-5103) Adding non existent and not required keystore fails
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFCORE-5103?page=com.atlassian.jira.plug... ]
Farah Juma commented on WFCORE-5103:
------------------------------------
[~mmazanek] Thanks for confirming! Did you want to assign this one to yourself to update the error message so it better describes the actual problem?
> Adding non existent and not required keystore fails
> ---------------------------------------------------
>
> Key: WFCORE-5103
> URL: https://issues.redhat.com/browse/WFCORE-5103
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jean Francois Denise
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 13.0.0.Beta6
>
>
> We are in a case where a CLI script is executed in an embedded server. They keystore added doesn't exist locally when the script is run. The operation is:
> /subsystem=elytron/key-store=keystore:add(required=false, path="/etc/foo/keystore.jks", credential-reference=\{clear-text=${keystore.password}})
> Error:
> "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.keystore" => "WFLYELY00004: Unable to start the service.
> [ERROR] Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00022: KeyStore file '/etc/wf-secrets/keystore.jks' does not exist and required."}},
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFCORE-5103) Adding non existent and not required keystore fails
by Martin Mazánek (Jira)
[ https://issues.redhat.com/browse/WFCORE-5103?page=com.atlassian.jira.plug... ]
Martin Mazánek commented on WFCORE-5103:
----------------------------------------
In this case the behaviour is correct. If the file does not exist, there is no way of decoding the correct keystore type without explicitly defining it or without having a default type for scenarios like this. Although the Exception thrown should be fixed to better describe the problem
> Adding non existent and not required keystore fails
> ---------------------------------------------------
>
> Key: WFCORE-5103
> URL: https://issues.redhat.com/browse/WFCORE-5103
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jean Francois Denise
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 13.0.0.Beta6
>
>
> We are in a case where a CLI script is executed in an embedded server. They keystore added doesn't exist locally when the script is run. The operation is:
> /subsystem=elytron/key-store=keystore:add(required=false, path="/etc/foo/keystore.jks", credential-reference=\{clear-text=${keystore.password}})
> Error:
> "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.keystore" => "WFLYELY00004: Unable to start the service.
> [ERROR] Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00022: KeyStore file '/etc/wf-secrets/keystore.jks' does not exist and required."}},
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (DROOLS-5608) Cannot use method chaining as source for facts
by Ciprian Chiru (Jira)
[ https://issues.redhat.com/browse/DROOLS-5608?page=com.atlassian.jira.plug... ]
Ciprian Chiru commented on DROOLS-5608:
---------------------------------------
[~lucamolteni] , yes it is broken. Starting with version 7.32.0.Final which seems to have introduced some breaking changes.
it fails with:
{code:java}
2020-09-01 09:04:59,970 INFO [org.example.drools.service.RulesSession] (main) Message [id=1, kieBase=defaultKieBase, level=ERROR, path=[...]/target/classes/rules/dummy-rule.drl, line=-1, column=0
text=Unable to Analyse Expression Optional.of($colorVal).orElse("blah"):
class sun.reflect.generics.reflectiveObjects.TypeVariableImpl cannot be cast to class java.lang.reflect.ParameterizedType (sun.reflect.generics.reflectiveObjects.TypeVariableImpl and java.lang.reflect.ParameterizedType are in module java.base of loader 'bootstrap')]
{code}
> Cannot use method chaining as source for facts
> ----------------------------------------------
>
> Key: DROOLS-5608
> URL: https://issues.redhat.com/browse/DROOLS-5608
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.42.0.Final
> Reporter: Ciprian Chiru
> Assignee: Luca Molteni
> Priority: Major
>
> Given the sample rule below:
> {code:java}
> import java.util.*;
> global java.util.Set controlSet;
> rule "will execute per each Measurement having ID color"
> no-loop
> when
> Measurement( id == "color", $colorVal : val )
> String() from Optional.of($colorVal).orElse("blah")
> then
> controlSet.add($colorVal);
> end{code}
>
> Compiling the resulting model fails with:
> {code:java}
> .../target/generated-sources/drools-model-compiler/main/java/rules/Rules79f20b1c9ba841128eaf4b2dbb336819RuleMethods0.java:[24,129] cannot find symbol
> [ERROR] symbol: variable $colorVal
> [ERROR] location: class rules.Rules79f20b1c9ba841128eaf4b2dbb336819RuleMethods0{code}
> Can be reproduced with _7.43.0-SNAPSHOT_
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFWIP-342) Bootable JAR - RESTEasy JAXB end-point return unexpected 400 response
by Jean Francois Denise (Jira)
[ https://issues.redhat.com/browse/WFWIP-342?page=com.atlassian.jira.plugin... ]
Jean Francois Denise commented on WFWIP-342:
--------------------------------------------
[~mkopecky], is it an issue also observed with pure galleon provisioning of the server? It could be an issue larger than just Bootable JAR packaging caused by the galleon provisioning of layers (jaxrs-server and microprofile-config).
> Bootable JAR - RESTEasy JAXB end-point return unexpected 400 response
> ---------------------------------------------------------------------
>
> Key: WFWIP-342
> URL: https://issues.redhat.com/browse/WFWIP-342
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Marek Kopecky
> Assignee: Jean Francois Denise
> Priority: Blocker
>
> RFE link: EAP7-1385
> RESTEasy JAXB end-point on bootable jar return unexpected 400 response with these security params:
> {code:xml}
> <context-param>
> <param-name>resteasy.document.secure.processing.feature</param-name>
> <param-value>true</param-value>
> </context-param>
> <context-param>
> <param-name>resteasy.document.secure.disableDTDs</param-name>
> <param-value>false</param-value>
> </context-param>
> <context-param>
> <param-name>resteasy.document.expand.entity.references</param-name>
> <param-value>false</param-value>
> </context-param>
> {code}
> Used layers:
> * jaxrs-server
> * microprofile-config
> Although this test is security related, AFAIK this is not related with legacy-security/elytron configuration, because related params are used in javax.xml.parsers.DocumentBuilderFactory directly from RESTEasy. Anyway let me know if I'm wrong.
> Steps to reproduce:
> # use installed WF version with reasonable layers, eg: WF_VERSION=21.0.0.Beta1-SNAPSHOT #
> # git clone git@github.com:marekkopecky/Resteasy.git -b bootable-jar-3-12-secure-processing
> # cd Resteasy
> # mvn install -DskipTests -Dcheckstyle.skip=true
> # cd testsuite
> # mvn install:install-file -Dpackaging=pom -Dfile=pom.xml -DpomFile=pom.xml
> # cd integration-tests
> # mvn clean install -Dts.bootable -Ddefault=false -Ddisable.microprofile.tests -Dserver.version=${WF_VERSION} -Dserver.home=placeholder -Dcheckstyle.skip=true -Denforcer.skip -Dcheckstyle.skip=true -Dmaven.test.redirectTestOutputToFile=false
> I can move these steps outside of TS, but I believe that TS doesn't affects this bootable jar behaviour, so it doesn't seem to be necessary.
> I see just this unexpected&suspicious console output although I'm not sure whether it's related or not:
> {noformat}
> [org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 189; External DTD: Failed to read external DTD 'SecureProcessing_external.dtd', because 'file' access is not allowed due to restriction set by the accessExternalDTD property.]
> {noformat}
> cc: [~fburzigo], [~yersan], [~asoldano], [~ron_sigal]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFWIP-342) Bootable JAR - RESTEasy JAXB end-point return unexpected 400 response
by Marek Kopecky (Jira)
[ https://issues.redhat.com/browse/WFWIP-342?page=com.atlassian.jira.plugin... ]
Marek Kopecky commented on WFWIP-342:
-------------------------------------
I also see similar behaviour on SecureProcessing2Test and ExternalParameterEntityTest tests from RESTEasy TS
> Bootable JAR - RESTEasy JAXB end-point return unexpected 400 response
> ---------------------------------------------------------------------
>
> Key: WFWIP-342
> URL: https://issues.redhat.com/browse/WFWIP-342
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Marek Kopecky
> Assignee: Jean Francois Denise
> Priority: Blocker
>
> RFE link: EAP7-1385
> RESTEasy JAXB end-point on bootable jar return unexpected 400 response with these security params:
> {code:xml}
> <context-param>
> <param-name>resteasy.document.secure.processing.feature</param-name>
> <param-value>true</param-value>
> </context-param>
> <context-param>
> <param-name>resteasy.document.secure.disableDTDs</param-name>
> <param-value>false</param-value>
> </context-param>
> <context-param>
> <param-name>resteasy.document.expand.entity.references</param-name>
> <param-value>false</param-value>
> </context-param>
> {code}
> Used layers:
> * jaxrs-server
> * microprofile-config
> Although this test is security related, AFAIK this is not related with legacy-security/elytron configuration, because related params are used in javax.xml.parsers.DocumentBuilderFactory directly from RESTEasy. Anyway let me know if I'm wrong.
> Steps to reproduce:
> # use installed WF version with reasonable layers, eg: WF_VERSION=21.0.0.Beta1-SNAPSHOT #
> # git clone git@github.com:marekkopecky/Resteasy.git -b bootable-jar-3-12-secure-processing
> # cd Resteasy
> # mvn install -DskipTests -Dcheckstyle.skip=true
> # cd testsuite
> # mvn install:install-file -Dpackaging=pom -Dfile=pom.xml -DpomFile=pom.xml
> # cd integration-tests
> # mvn clean install -Dts.bootable -Ddefault=false -Ddisable.microprofile.tests -Dserver.version=${WF_VERSION} -Dserver.home=placeholder -Dcheckstyle.skip=true -Denforcer.skip -Dcheckstyle.skip=true -Dmaven.test.redirectTestOutputToFile=false
> I can move these steps outside of TS, but I believe that TS doesn't affects this bootable jar behaviour, so it doesn't seem to be necessary.
> I see just this unexpected&suspicious console output although I'm not sure whether it's related or not:
> {noformat}
> [org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 189; External DTD: Failed to read external DTD 'SecureProcessing_external.dtd', because 'file' access is not allowed due to restriction set by the accessExternalDTD property.]
> {noformat}
> cc: [~fburzigo], [~yersan], [~asoldano], [~ron_sigal]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months