[JBoss JIRA] (ELY-1578) Upgrade to Fedora 28 breaks FIPS scenarios
by Rich Lucente (JIRA)
[ https://issues.jboss.org/browse/ELY-1578?page=com.atlassian.jira.plugin.s... ]
Rich Lucente commented on ELY-1578:
-----------------------------------
@choma I was able to prefix the database directory with "dbm:" and that generated the older style files. The commands would look like:
{code:java}
mkdir -p $HOME/fipsdb
modutil -force -dbdir dbm:$HOME/fipsdb -create
modutil -force -dbdir dbm:$HOME/fipsdb -fips true
{code}
I agree that sql: as the default does cause issues with script backwards compatibility.
> Upgrade to Fedora 28 breaks FIPS scenarios
> ------------------------------------------
>
> Key: ELY-1578
> URL: https://issues.jboss.org/browse/ELY-1578
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.3.1.Final
> Reporter: Martin Choma
>
> On Fedora 28 I get
> {code}
> 14:52:28,813 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.as: org.jboss.msc.service.StartException in service jboss.as: Failed to start service
> at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1706)
> at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.base/java.lang.Thread.run(Thread.java:844)
> Caused by: java.security.ProviderException: NSS module not available: fips
> at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:278)
> at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:113)
> at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:110)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:110)
> at java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:247)
> at java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:238)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.base/sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:238)
> at java.base/sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:218)
> at java.base/sun.security.jca.ProviderList.getProvider(ProviderList.java:266)
> at java.base/sun.security.jca.ProviderList.getService(ProviderList.java:379)
> at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:157)
> at java.base/java.security.Security.getImpl(Security.java:697)
> at java.base/java.security.MessageDigest.getInstance(MessageDigest.java:178)
> at org.jboss.as.deployment-repository(a)5.0.0.Alpha-redhat-20180502//org.jboss.as.repository.ContentRepositoryImpl.<init>(ContentRepositoryImpl.java:90)
> at org.jboss.as.deployment-repository@5.0.0.Alpha-redhat-20180502//org.jboss.as.repository.ContentRepository$Factory.addService(ContentRepository.java:185)
> at org.jboss.as.server@5.0.0.Alpha-redhat-20180502//org.jboss.as.server.ApplicationServerService.start(ApplicationServerService.java:144)
> at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
> at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
> ... 6 more
> {code}
> In Fedora 28 there is nss 3.36.1 (dnf info nss.x86_64)
> In Fedora 27 there was 3.33 https://fedora.pkgs.org/27/fedora-x86_64/nss-3.33.0-1.0.fc27.x86_64.rpm.html
> In nss 3.35 there was switch of format to SQL [1]
> ??Applications using NSS may explicitly request to use a specific database format, by adding a type prefix to the database directory, provided at NSS initialization time. ??
> But I am not sure how to define that in java. I am using
> {code:pkcs11.cfg}
> name = testPkcs
> nssLibraryDirectory = /usr/lib64
> nssSecmodDirectory = /opt/java/jdk-9.0.1_fips/fips/nssdb
> nssDbMode = readOnly
> nssModule = fips
> {code}
> I am awaer there is probably nothing that can be done in Elytron. I think it is matter of NSS/SunPKCS11 configuration. I create this JIRA as a place for finding out what the problem is.
> [1] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.35_re...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (ELY-1578) Upgrade to Fedora 28 breaks FIPS scenarios
by Rich Lucente (JIRA)
[ https://issues.jboss.org/browse/ELY-1578?page=com.atlassian.jira.plugin.s... ]
Rich Lucente edited comment on ELY-1578 at 5/7/18 10:18 AM:
------------------------------------------------------------
I was able to prefix the database directory with "dbm:" and that generated the older style files. The commands would look like:
{code:java}
mkdir -p $HOME/fipsdb
modutil -force -dbdir dbm:$HOME/fipsdb -create
modutil -force -dbdir dbm:$HOME/fipsdb -fips true
{code}
I agree that sql: as the default does cause issues with script backwards compatibility.
was (Author: rlucente-se-jboss):
@choma I was able to prefix the database directory with "dbm:" and that generated the older style files. The commands would look like:
{code:java}
mkdir -p $HOME/fipsdb
modutil -force -dbdir dbm:$HOME/fipsdb -create
modutil -force -dbdir dbm:$HOME/fipsdb -fips true
{code}
I agree that sql: as the default does cause issues with script backwards compatibility.
> Upgrade to Fedora 28 breaks FIPS scenarios
> ------------------------------------------
>
> Key: ELY-1578
> URL: https://issues.jboss.org/browse/ELY-1578
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.3.1.Final
> Reporter: Martin Choma
>
> On Fedora 28 I get
> {code}
> 14:52:28,813 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.as: org.jboss.msc.service.StartException in service jboss.as: Failed to start service
> at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1706)
> at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.base/java.lang.Thread.run(Thread.java:844)
> Caused by: java.security.ProviderException: NSS module not available: fips
> at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:278)
> at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:113)
> at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:110)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:110)
> at java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:247)
> at java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:238)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.base/sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:238)
> at java.base/sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:218)
> at java.base/sun.security.jca.ProviderList.getProvider(ProviderList.java:266)
> at java.base/sun.security.jca.ProviderList.getService(ProviderList.java:379)
> at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:157)
> at java.base/java.security.Security.getImpl(Security.java:697)
> at java.base/java.security.MessageDigest.getInstance(MessageDigest.java:178)
> at org.jboss.as.deployment-repository(a)5.0.0.Alpha-redhat-20180502//org.jboss.as.repository.ContentRepositoryImpl.<init>(ContentRepositoryImpl.java:90)
> at org.jboss.as.deployment-repository@5.0.0.Alpha-redhat-20180502//org.jboss.as.repository.ContentRepository$Factory.addService(ContentRepository.java:185)
> at org.jboss.as.server@5.0.0.Alpha-redhat-20180502//org.jboss.as.server.ApplicationServerService.start(ApplicationServerService.java:144)
> at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
> at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
> ... 6 more
> {code}
> In Fedora 28 there is nss 3.36.1 (dnf info nss.x86_64)
> In Fedora 27 there was 3.33 https://fedora.pkgs.org/27/fedora-x86_64/nss-3.33.0-1.0.fc27.x86_64.rpm.html
> In nss 3.35 there was switch of format to SQL [1]
> ??Applications using NSS may explicitly request to use a specific database format, by adding a type prefix to the database directory, provided at NSS initialization time. ??
> But I am not sure how to define that in java. I am using
> {code:pkcs11.cfg}
> name = testPkcs
> nssLibraryDirectory = /usr/lib64
> nssSecmodDirectory = /opt/java/jdk-9.0.1_fips/fips/nssdb
> nssDbMode = readOnly
> nssModule = fips
> {code}
> I am awaer there is probably nothing that can be done in Elytron. I think it is matter of NSS/SunPKCS11 configuration. I create this JIRA as a place for finding out what the problem is.
> [1] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.35_re...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (JBJCA-1376) if a security domain is used for an XA datasource in WildFly 11 and later, recovery will not work
by Martin Simka (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1376?page=com.atlassian.jira.plugin... ]
Martin Simka resolved JBJCA-1376.
---------------------------------
Fix Version/s: 1.4.10
Resolution: Done
> if a security domain is used for an XA datasource in WildFly 11 and later, recovery will not work
> -------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1376
> URL: https://issues.jboss.org/browse/JBJCA-1376
> Project: IronJacamar
> Issue Type: Bug
> Components: Deployer
> Affects Versions: 1.4.6, 1.4.7, 1.4.8, 1.4.9
> Reporter: Martin Simka
> Assignee: Martin Simka
> Priority: Critical
> Fix For: 1.4.10
>
>
> {noformat}
> 17:05:32,521 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/datasources/oraclexa1
> 17:05:32,521 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/datasources/oraclexa1
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2530) DMN Decision Table - wrong evaluation of parameter named "product"
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2530?page=com.atlassian.jira.plugi... ]
Edson Tirelli reassigned DROOLS-2530:
-------------------------------------
Assignee: Fedor Gavrilov (was: Matteo Mortari)
> DMN Decision Table - wrong evaluation of parameter named "product"
> ------------------------------------------------------------------
>
> Key: DROOLS-2530
> URL: https://issues.jboss.org/browse/DROOLS-2530
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.5.0.Final, 7.6.0.Final, 7.7.0.Final
> Reporter: David Le Moing
> Assignee: Fedor Gavrilov
> Priority: Critical
> Fix For: 7.8.0.Final
>
> Attachments: product_issue.dmn
>
>
> We have an input named "product" that is used in a decision table.
> We upgraded to Drools 7.7.0.Final and noticed that now, what was evaluated was not the object passed as parameter, but an object of type ProductFunction.
> The same issue is present in version 7.5.0.Final and 7.6.0.Final. It was working fine previously.
> I think the issue is coming from the method getAllValues() of EvaluationContextImpl. Maybe the stack should be reversed before iterating over it and putting the values in the map.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10241) -secmgr property doesn't work in wsprovide&&wsconsume scripts
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-10241?page=com.atlassian.jira.plugin... ]
Alessio Soldano updated WFLY-10241:
-----------------------------------
Priority: Major (was: Blocker)
> -secmgr property doesn't work in wsprovide&&wsconsume scripts
> -------------------------------------------------------------
>
> Key: WFLY-10241
> URL: https://issues.jboss.org/browse/WFLY-10241
> Project: WildFly
> Issue Type: Bug
> Components: Scripts, Web Services
> Reporter: Marek Kopecký
> Assignee: R Searls
>
> standalone&&domain&&appclient scripts support {{-secmgr}} command line argument or {{SECMGR=true}} env property, see the details [here|https://github.com/wildfly/wildfly-core/blob/master/core-feature-pac...]
> wsprovide&&wsconsume scripts should be able to use the same configuration settings.
> But scripts behaviour is different in these two scenarios, so {{-secmgr}} command line argument is not handled correctly:
> {noformat}
> [mkopecky@dhcp-10-40-5-128 bin]$ java -version
> java version "1.8.0_162"
> Java(TM) SE Runtime Environment (build 1.8.0_162-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, mixed mode)
> [mkopecky@dhcp-10-40-5-128 bin]$ export SECMGR=""
> [mkopecky@dhcp-10-40-5-128 bin]$ ./wsconsume.sh -secmgr https://raw.githubusercontent.com/jbossws/jbossws-cxf/master/modules/test...
> Could not find log4j.properties or log4j.xml configuration, logging to console.
> Loading FrontEnd jaxws ...
> Loading DataBinding jaxb ...
> wsdl2java -compile -exsh false -d /home/mkopecky/playground/wf/wfly.23/wfly.23/bin/output/tmp5356716 -verbose -classdir /home/mkopecky/playground/wf/wfly.23/wfly.23/bin/output -allowElementReferences https://raw.githubusercontent.com/jbossws/jbossws-cxf/master/modules/test...
> wsdl2java - Apache CXF 3.2.4
> [mkopecky@dhcp-10-40-5-128 bin]$ export SECMGR="true"
> [mkopecky@dhcp-10-40-5-128 bin]$ ./wsconsume.sh https://raw.githubusercontent.com/jbossws/jbossws-cxf/master/modules/test... not find log4j.properties or log4j.xml configuration, logging to console.
> Loading FrontEnd jaxws ...
> Loading DataBinding jaxb ...
> wsdl2java -compile -exsh false -d /home/mkopecky/playground/wf/wfly.23/wfly.23/bin/output/tmp1569691 -verbose -classdir /home/mkopecky/playground/wf/wfly.23/wfly.23/bin/output -allowElementReferences https://raw.githubusercontent.com/jbossws/jbossws-cxf/master/modules/test...
> wsdl2java - Apache CXF 3.2.4
> JBWS024002: Failed to invoke org.apache.cxf.tools.wsdlto.WSDLToJava
> org.apache.cxf.tools.common.ToolException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/mkopecky/playground/wf/wfly.23/wfly.23/bin/output/tmp1569691/org/openuri/_2004/_04/helloworld/EndpointInterface.java" "read")" in code source "(file:/home/mkopecky/base/jdk1.8.0_162/lib/tools.jar <no signer certificates>)" of "java.net.FactoryURLClassLoader@6fd5717c")
> at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:420)
> at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
> at org.jboss.wsf.stack.cxf.tools.CXFConsumerImpl.consume(CXFConsumerImpl.java:313)
> at org.jboss.ws.tools.cmd.WSConsume.importServices(WSConsume.java:298)
> at org.jboss.ws.tools.cmd.WSConsume.mainInternal(WSConsume.java:108)
> at org.jboss.ws.tools.cmd.WSConsume.main(WSConsume.java:96)
> at org.jboss.modules.Module.runMainMethod(Module.java:348)
> at org.jboss.modules.Module.run(Module.java:328)
> at org.jboss.modules.Main.main(Main.java:557)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/mkopecky/playground/wf/wfly.23/wfly.23/bin/output/tmp1569691/org/openuri/_2004/_04/helloworld/EndpointInterface.java" "read")" in code source "(file:/home/mkopecky/base/jdk1.8.0_162/lib/tools.jar <no signer certificates>)" of "java.net.FactoryURLClassLoader@6fd5717c")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:360)
> at java.io.File.isDirectory(File.java:844)
> at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:69)
> at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:64)
> at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromFiles(JavacFileManager.java:785)
> at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromStrings(JavacFileManager.java:185)
> at org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:202)
> at org.apache.cxf.common.util.Compiler.compileFiles(Compiler.java:141)
> at org.apache.cxf.tools.common.ClassUtils.compile(ClassUtils.java:123)
> at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:303)
> at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:164)
> at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:412)
> ... 9 more
> [mkopecky@dhcp-10-40-5-128 bin]$
> {noformat}
> In first example, secmgr is not activated (wrong behaviour, that should be fixed by this jira). In second example, secmgr is activated, exception should be handled in WFLY-10240.
> cc: [~jbliznak]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (SWSQE-203) Apply "sysctl -w vm.max_map_count=262144 " to B12 cluster
by Guilherme Baufaker Rêgo (JIRA)
[ https://issues.jboss.org/browse/SWSQE-203?page=com.atlassian.jira.plugin.... ]
Guilherme Baufaker Rêgo commented on SWSQE-203:
-----------------------------------------------
Applied to all nodes of the cluster.
ssh root(a)b12.jonqe.lab.eng.bos.redhat.com ✔ 10023 09:55:18
Last login: Wed Apr 25 18:30:13 2018 from 10.97.116.68
[root@b12 ~]# oc get nodes
NAME STATUS ROLES AGE VERSION
b11.jonqe.lab.eng.bos.redhat.com Ready compute 23d v1.9.1+a0ce1bc657
b12.jonqe.lab.eng.bos.redhat.com Ready master 23d v1.9.1+a0ce1bc657
b14.jonqe.lab.eng.bos.redhat.com Ready compute 11d v1.9.1+a0ce1bc657
[root@b12 ~]# sudo sysctl -w vm.max_map_count=262144
vm.max_map_count = 262144
[root@b12 ~]# exit
logout
Connection to b12.jonqe.lab.eng.bos.redhat.com closed.
gbaufake@lenovo-t460 ~ ssh root(a)b11.jonqe.lab.eng.bos.redhat.com ✔ 10024 09:55:55
Last login: Wed Apr 25 10:28:48 2018 from 10.97.116.68
[root@b11 ~]# sudo sysctl -w vm.max_map_count=262144
vm.max_map_count = 262144
[root@b11 ~]# exit
logout
Connection to b11.jonqe.lab.eng.bos.redhat.com closed.
gbaufake@lenovo-t460 ~ ssh root(a)b14.jonqe.lab.eng.bos.redhat.com ✔ 10025 09:56:05
Last login: Mon Apr 30 11:39:01 2018 from 10.97.116.15
[root@b14 ~]# sudo sysctl -w vm.max_map_count=262144
vm.max_map_count = 262144
> Apply "sysctl -w vm.max_map_count=262144 " to B12 cluster
> ---------------------------------------------------------
>
> Key: SWSQE-203
> URL: https://issues.jboss.org/browse/SWSQE-203
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Kevin Earls
> Assignee: Guilherme Baufaker Rêgo
>
> As part of https://issues.jboss.org/browse/SWSQE-113 the command "sudo sysctl -w vm.max_map_count=262144 " was executed on the B12 cluster in order to allow ElasticSearch to run correctly.
> However I tried to run a performance test this morning and the ES deployment failed with
> ERROR: [1] bootstrap checks failed
> [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
> Can you reapply this and do whatever is needed to make sure it persists over cluster rebuilds or restarts? Thanks.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2530) DMN Decision Table - wrong evaluation of parameter named "product"
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2530?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-2530:
---------------------------------------
[~dlemoing] thank you for reporting, it does sound like the resolution order for names in scope might be wrong. We will fix it.
> DMN Decision Table - wrong evaluation of parameter named "product"
> ------------------------------------------------------------------
>
> Key: DROOLS-2530
> URL: https://issues.jboss.org/browse/DROOLS-2530
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.5.0.Final, 7.6.0.Final, 7.7.0.Final
> Reporter: David Le Moing
> Assignee: Matteo Mortari
> Priority: Critical
> Fix For: 7.8.0.Final
>
> Attachments: product_issue.dmn
>
>
> We have an input named "product" that is used in a decision table.
> We upgraded to Drools 7.7.0.Final and noticed that now, what was evaluated was not the object passed as parameter, but an object of type ProductFunction.
> The same issue is present in version 7.5.0.Final and 7.6.0.Final. It was working fine previously.
> I think the issue is coming from the method getAllValues() of EvaluationContextImpl. Maybe the stack should be reversed before iterating over it and putting the values in the map.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2530) DMN Decision Table - wrong evaluation of parameter named "product"
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2530?page=com.atlassian.jira.plugi... ]
Edson Tirelli reassigned DROOLS-2530:
-------------------------------------
Assignee: Matteo Mortari (was: Edson Tirelli)
> DMN Decision Table - wrong evaluation of parameter named "product"
> ------------------------------------------------------------------
>
> Key: DROOLS-2530
> URL: https://issues.jboss.org/browse/DROOLS-2530
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.5.0.Final, 7.6.0.Final, 7.7.0.Final
> Reporter: David Le Moing
> Assignee: Matteo Mortari
> Priority: Critical
> Fix For: 7.8.0.Final
>
> Attachments: product_issue.dmn
>
>
> We have an input named "product" that is used in a decision table.
> We upgraded to Drools 7.7.0.Final and noticed that now, what was evaluated was not the object passed as parameter, but an object of type ProductFunction.
> The same issue is present in version 7.5.0.Final and 7.6.0.Final. It was working fine previously.
> I think the issue is coming from the method getAllValues() of EvaluationContextImpl. Maybe the stack should be reversed before iterating over it and putting the values in the map.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3806) Eliminate code that was using transitive MSC dependencies
by Richard Opalka (JIRA)
Richard Opalka created WFCORE-3806:
--------------------------------------
Summary: Eliminate code that was using transitive MSC dependencies
Key: WFCORE-3806
URL: https://issues.jboss.org/browse/WFCORE-3806
Project: WildFly Core
Issue Type: Enhancement
Components: Server
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: 5.0.0.Alpha6
Prior MSC 1.2.8 stability monitors were reporting problems if
some transitive dependency wasn't available. This has changed
since MSC 1.2.8. There is no notion of transitive
dependencies in JBoss MSC anymore. If stability monitor detects
a problem it is always immediate dependency of monitored controller.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months