[JBoss JIRA] (DROOLS-4522) Adding "expression" type handling
by Yeser Amer (Jira)
[ https://issues.jboss.org/browse/DROOLS-4522?page=com.atlassian.jira.plugi... ]
Yeser Amer updated DROOLS-4522:
-------------------------------
Summary: Adding "expression" type handling (was: Add an "expression" property for every complex type in Scenario Testing)
> Adding "expression" type handling
> ---------------------------------
>
> Key: DROOLS-4522
> URL: https://issues.jboss.org/browse/DROOLS-4522
> Project: Drools
> Issue Type: Feature Request
> Components: Scenario Simulation and Testing
> Reporter: Yeser Amer
> Assignee: Yeser Amer
> Priority: Major
> Attachments: can-be-suspended-expression.webm
>
>
> Basically, with the changes introduced in this PR, every complex type object in Scenario has an additional property ("expression") where it will be possible to add expression logic to the referred object (fact). At the moment, the changes involve only front-end side.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-4684) Parser and Canonical Model Compiler error on Conditional Named Consequence
by Duncan Doyle (Jira)
Duncan Doyle created DROOLS-4684:
------------------------------------
Summary: Parser and Canonical Model Compiler error on Conditional Named Consequence
Key: DROOLS-4684
URL: https://issues.jboss.org/browse/DROOLS-4684
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.28.0.Final
Environment: macOS 10.14.6, OpenJDK 1.8.0_222
Reporter: Duncan Doyle
Assignee: Mario Fusco
See reproducer here: https://github.com/DuncanDoyle/drools-conditional-named-consequence-issue
When you use a Conditional Named Consequence {code}if{code} definition directly after an {code}accumulate{code}, Drools gives the following error when parsing the DRL:
{code}
[ERROR] Failed to execute goal org.kie:kie-maven-plugin:7.28.0.Final:build (default-build) on project drools-conditional-named-consequence-issue: Execution default-build of goal org.kie:kie-maven-plugin:7.28.0.Final:build failed: Unable to get KieModule, Errors Existed: Error Messages:
[ERROR] Message [id=1, kieBase=defaultKieBase, level=ERROR, path=rules.drl, line=19, column=0
[ERROR] text=Unable to resolve ObjectType 'if']
[ERROR] ---
[ERROR] Warning Messages:
[ERROR] ---
[ERROR] Info Messages:
[ERROR]
{code}
When you add a constraint between the {code}accumulate{code} and the {code}if{code} statement of the Conditional Named Consequence, it works fine.
Also when you try to generate the canonical model from a DRL that contains a Conditional Named Consequence, you get the following error:
{code}
[ERROR] Failed to execute goal org.kie:kie-maven-plugin:7.28.0.Final:generateModel (default-generateModel) on project drools-conditional-named-consequence-issue: A type incompatibility occurred while executing org.kie:kie-maven-plugin:7.28.0.Final:generateModel: org.drools.compiler.lang.descr.NamedConsequenceDescr cannot be cast to org.drools.compiler.lang.descr.PatternDescr
{code}
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-12563) org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL flag ignored when WARs are embedded in EAR
by Romain Pelisse (Jira)
[ https://issues.jboss.org/browse/WFLY-12563?page=com.atlassian.jira.plugin... ]
Romain Pelisse updated WFLY-12563:
----------------------------------
Labels: downstream_dependency (was: )
> org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL flag ignored when WARs are embedded in EAR
> ------------------------------------------------------------------------------------
>
> Key: WFLY-12563
> URL: https://issues.jboss.org/browse/WFLY-12563
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 15.0.0.Final, 16.0.0.Final, 17.0.0.Final, 18.0.0.Beta1
> Reporter: Bartosz Ryndak
> Assignee: Teresa Miyar Gil
> Priority: Critical
> Labels: downstream_dependency
> Fix For: 19.0.0.Beta1
>
>
> Due to changes indroduced to fix bug WFLY-10796 it is no longer possible to configure wars embedded in ear to bundle jsf implementation.
> Changes made in file JSFDependencyProcessor.java in commit 40f72548985a9f5ca31317b01a4a0ce09ee759aa
> From:
> {code}
> final DeploymentUnit tl = deploymentUnit.getParent() == null ? deploymentUnit : deploymentUnit.getParent();
> String jsfVersion = JsfVersionMarker.getVersion(tl);
> {code}
> To:
> {code}
> String jsfVersion = JsfVersionMarker.getVersion(deploymentUnit);
> {code}
> modified the way jsf version is aquired. Before the change it was always taken from top level deployment. After it is taken directly from scanned deployment unit without searching in parent. Unfortunately there was no matching change in a way context params from web.xml are processed in JSFVersionProcessor:
> {code}
> final DeploymentUnit topLevelDeployment = deploymentUnit.getParent() == null ? deploymentUnit : deploymentUnit.getParent();
> final WarMetaData metaData = deploymentUnit.getAttachment(WarMetaData.ATTACHMENT_KEY);
> List<ParamValueMetaData> contextParams = new ArrayList<ParamValueMetaData>();
> if ((metaData.getWebMetaData() != null) && (metaData.getWebMetaData().getContextParams() != null)) {
> contextParams.addAll(metaData.getWebMetaData().getContextParams());
> }
> for (final ParamValueMetaData param : contextParams) {
> if ((param.getParamName().equals(WAR_BUNDLES_JSF_IMPL_PARAM) &&
> (param.getParamValue() != null) &&
> (param.getParamValue().toLowerCase(Locale.ENGLISH).equals("true")))) {
> JsfVersionMarker.setVersion(topLevelDeployment, JsfVersionMarker.WAR_BUNDLES_JSF_IMPL);
> break; // WAR_BUNDLES_JSF_IMPL always wins
> }
> if (param.getParamName().equals(JSF_CONFIG_NAME_PARAM)) {
> JsfVersionMarker.setVersion(topLevelDeployment, param.getParamValue());
> break;
> }
> }
> {code}
> So the information about org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL flag is only set in top level deployment unit.
> This causes Mojarra-2.0 to be returned as jsf version during checks in JSFDependencyProcessor for embedded wars and leads to initialization of default mojarra implementation before bundled implementation is processed. As both implementations are loaded class conflicts occur and it is not possible to properly initialize jsf. In case of myfaces this leads to below error:
> {code}
> 2019-09-16 10:46:23,405 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 86) MSC000001: Failed to start service jboss.deployment.subunit."xxx.ear"."yyy.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.subunit."xxx.ear"."yyy.war".undertow-deployment: java.lang.RuntimeException: java.lang.IllegalStateException: Could not find backup for factory javax.faces.application.ApplicationFactory.
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: Could not find backup for factory javax.faces.application.ApplicationFactory.
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:252)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:96)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78)
> ... 8 more
> Caused by: java.lang.IllegalStateException: Could not find backup for factory javax.faces.application.ApplicationFactory.
> at javax.faces.FactoryFinderInstance.notNullFactory(FactoryFinderInstance.java:524)
> at javax.faces.FactoryFinderInstance.getFactory(FactoryFinderInstance.java:207)
> at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:279)
> at org.apache.myfaces.context.servlet.FacesContextImplBase.getApplication(FacesContextImplBase.java:159)
> at org.apache.myfaces.context.servlet.FacesContextImplBase.getELContext(FacesContextImplBase.java:210)
> at javax.faces.component.UIViewRoot.setLocale(UIViewRoot.java:1602)
> at org.apache.myfaces.webapp.AbstractFacesInitializer._createFacesContext(AbstractFacesInitializer.java:477)
> at org.apache.myfaces.webapp.AbstractFacesInitializer.initStartupFacesContext(AbstractFacesInitializer.java:449)
> at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:113)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:216)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:185)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:250)
> ... 10 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (JGRP-2391) BindException on Windows
by Thorsten Marx (Jira)
[ https://issues.jboss.org/browse/JGRP-2391?page=com.atlassian.jira.plugin.... ]
Thorsten Marx commented on JGRP-2391:
-------------------------------------
Sorry, I did not have any windows image.
It was introduced by a change made for the 4.1.* versions.
This is more or less the code used in the current version that didn't work on windows:
{code}
InetSocketAddress isa = new InetSocketAddress("239.255.0.113", 1234);
MulticastSocket mcs = new MulticastSocket(isa);
{code}
This is a working version that works on windows.
{code}
InetAddress ia = InetAddress.getByName("239.255.0.113");
MulticastSocket mcs = new MulticastSocket(1234);
mcs.joinGroup(ia);
{code}
I don't know the reason for that change, but maybe this helps a bit.
> BindException on Windows
> ------------------------
>
> Key: JGRP-2391
> URL: https://issues.jboss.org/browse/JGRP-2391
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.0, 4.1.1, 4.1.2, 4.1.3, 4.1.4, 4.1.5, 4.1.6
> Environment: Openjdk 13
> Microsoft Windows 10
> Reporter: Thorsten Marx
> Assignee: Bela Ban
> Priority: Major
>
> After updating to jgroups 4.1.6 i get the following BindException
> {code}
> java.net.BindException: Cannot assign requested address: Cannot bind
> at java.base/java.net.TwoStacksPlainDatagramSocketImpl.bind0(Native Method)
> at java.base/java.net.TwoStacksPlainDatagramSocketImpl.bind0(TwoStacksPlainDatagramSocketImpl.java:114)
> at java.base/java.net.AbstractPlainDatagramSocketImpl.bind(AbstractPlainDatagramSocketImpl.java:117)
> at java.base/java.net.TwoStacksPlainDatagramSocketImpl.bind(TwoStacksPlainDatagramSocketImpl.java:98)
> at java.base/java.net.DatagramSocket.bind(DatagramSocket.java:395)
> at java.base/java.net.MulticastSocket.<init>(MulticastSocket.java:176)
> at org.jgroups.util.DefaultSocketFactory.createMulticastSocket(DefaultSocketFactory.java:92)
> at org.jgroups.stack.DiagnosticsHandler.startUDP(DiagnosticsHandler.java:180)
> at org.jgroups.stack.DiagnosticsHandler.start(DiagnosticsHandler.java:122)
> at org.jgroups.protocols.TP.startDiagnostics(TP.java:1031)
> at org.jgroups.protocols.TP.start(TP.java:938)
> at org.jgroups.protocols.UDP.start(UDP.java:295)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:888)
> at org.jgroups.JChannel.startStack(JChannel.java:980)
> at org.jgroups.JChannel._preConnect(JChannel.java:844)
> at org.jgroups.JChannel.connect(JChannel.java:349)
> at org.jgroups.JChannel.connect(JChannel.java:343)
> at com.thorstenmarx.webtools.cluster.JGroupsTest.simple(JGroupsTest.java:43)
> {code}
> It seems to be caused by https://stackoverflow.com/questions/14086740/how-to-create-a-new-multicas...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-4669) Scanner is not using container ClassLoader
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-4669?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-4669:
--------------------------------
Sprint: 2019 Week 44-46 (from Okt 28) (was: 2019 Week 41-43 (from Okt 7))
> Scanner is not using container ClassLoader
> ------------------------------------------
>
> Key: DROOLS-4669
> URL: https://issues.jboss.org/browse/DROOLS-4669
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.28.0.Final
> Environment: Java 11, Java 8, Linux Debian
> Reporter: Pavel Tavoda
> Assignee: Mario Fusco
> Priority: Major
> Attachments: drools-sample.zip
>
>
> I had issue with standard Spring project. My configuration ended with following exception:
> {code:java}
> Caused by: java.lang.RuntimeException: The Eclipse JDT Core jar is not in the classpath
> at org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration.setCompiler(JavaDialectConfiguration.java:117)
> {code}
> Because of this I have to setup KieSession this way:
> {code:java}
> KieServices kieServices = KieServices.Factory.get();
> ReleaseId kieRelease = kieServices.newReleaseId("sk.f4s", "encounter-rule", "1.0.0-SNAPSHOT");
> KieContainer kieContainer = kieServices.newKieContainer(kieRelease, this.getClass().getClassLoader());
> kieSession = kieContainer.newStatelessKieSession();
> {code}
> After this everything works fine. However I want to reload my kBase with scanner. I add following two lines:
> {code:java}
> kieScanner = kieServices.newKieScanner(kieContainer);
> kieScanner.start(1000l);
> {code}
> After this following exception is raised:
> {code}
> Exception in thread "Timer-0" java.lang.RuntimeException: Unable to load dialect 'org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration:java:org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration'
> at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.addDialect(KnowledgeBuilderConfigurationImpl.java:394)
> at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.buildDialectConfigurationMap(KnowledgeBuilderConfigurationImpl.java:380)
> at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.init(KnowledgeBuilderConfigurationImpl.java:235)
> at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.init(KnowledgeBuilderConfigurationImpl.java:187)
> at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.<init>(KnowledgeBuilderConfigurationImpl.java:155)
> at org.drools.compiler.kie.builder.impl.AbstractKieProject.getBuilderConfiguration(AbstractKieProject.java:302)
> at org.drools.compiler.kie.builder.impl.AbstractKieProject.createKnowledgeBuilder(AbstractKieProject.java:288)
> at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages(AbstractKieProject.java:213)
> at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:75)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:271)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieModule(KieBuilderImpl.java:264)
> at org.drools.compiler.kie.builder.impl.InternalKieModule.build(InternalKieModule.java:120)
> at org.kie.scanner.KieRepositoryScannerImpl.updateKieModule(KieRepositoryScannerImpl.java:200)
> at org.kie.scanner.KieRepositoryScannerImpl.internalUpdate(KieRepositoryScannerImpl.java:185)
> at org.kie.scanner.KieRepositoryScannerImpl.internalUpdate(KieRepositoryScannerImpl.java:55)
> at org.drools.compiler.kie.builder.impl.AbstractKieScanner.scanNow(AbstractKieScanner.java:147)
> at org.drools.compiler.kie.builder.impl.AbstractKieScanner$ScanTask.run(AbstractKieScanner.java:127)
> at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
> Caused by: java.lang.RuntimeException: The Eclipse JDT Core jar is not in the classpath
> at org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration.setCompiler(JavaDialectConfiguration.java:117)
> at org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration.init(JavaDialectConfiguration.java:78)
> at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.addDialect(KnowledgeBuilderConfigurationImpl.java:390)
> ... 18 more
> {code}
> I guess reason is that scanner is not using ClassLoader from KieContainer. Of course it will be better to fix reason why 'The Eclipse JDT Core jar is not in the classpath' is raised anyway because I'm using just standard Spring Web project with two Spring contexts (application and Web) what is very standard approach. Compiler IS awailable on classpath only Drools classloader doesn't see it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-4645) High memory consumption with JIT
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-4645?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-4645:
--------------------------------
Sprint: 2019 Week 44-46 (from Okt 28) (was: 2019 Week 41-43 (from Okt 7))
> High memory consumption with JIT
> --------------------------------
>
> Key: DROOLS-4645
> URL: https://issues.jboss.org/browse/DROOLS-4645
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.29.0.Final
> Reporter: Radovan Synek
> Assignee: Mario Fusco
> Priority: Critical
> Attachments: Screenshot from 2019-10-15 10-30-27.png, Screenshot from 2019-10-15 10-31-53.png
>
>
> Employee Rostering example for OptaPlanner shows excessive memory consumption, which is connected with Drools score calculation.
> Please see the reproducer - running it without drools JIT finishes on time with 3GB of memory while with drools JIT being active it fails due to "GC overhead limit exceeded" despite the fact it god twice as much memory.
> Logging (add -Dlogback.level.org.optaplanner=trace to the execute_jit.sh script) showed there is a huge pillar move changing ~hundreds of entities which takes seconds to calculate score. During this move's evaluation, the memory consumption increases to a point when GC takes over and later fails.
> Memory sampling and heap dump investigation showed there are ~10^7 objects of org.drools.core.reteoo.FromNodeLeftTuple class, taking more memory than any other data type in the VM.
> See the attached screenshots.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (JGRP-2391) BindException on Windows
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2391?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2391:
--------------------------------
Sorry, I don't use Windows. Do you have an image that I could try out?
> BindException on Windows
> ------------------------
>
> Key: JGRP-2391
> URL: https://issues.jboss.org/browse/JGRP-2391
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.0, 4.1.1, 4.1.2, 4.1.3, 4.1.4, 4.1.5, 4.1.6
> Environment: Openjdk 13
> Microsoft Windows 10
> Reporter: Thorsten Marx
> Assignee: Bela Ban
> Priority: Major
>
> After updating to jgroups 4.1.6 i get the following BindException
> {code}
> java.net.BindException: Cannot assign requested address: Cannot bind
> at java.base/java.net.TwoStacksPlainDatagramSocketImpl.bind0(Native Method)
> at java.base/java.net.TwoStacksPlainDatagramSocketImpl.bind0(TwoStacksPlainDatagramSocketImpl.java:114)
> at java.base/java.net.AbstractPlainDatagramSocketImpl.bind(AbstractPlainDatagramSocketImpl.java:117)
> at java.base/java.net.TwoStacksPlainDatagramSocketImpl.bind(TwoStacksPlainDatagramSocketImpl.java:98)
> at java.base/java.net.DatagramSocket.bind(DatagramSocket.java:395)
> at java.base/java.net.MulticastSocket.<init>(MulticastSocket.java:176)
> at org.jgroups.util.DefaultSocketFactory.createMulticastSocket(DefaultSocketFactory.java:92)
> at org.jgroups.stack.DiagnosticsHandler.startUDP(DiagnosticsHandler.java:180)
> at org.jgroups.stack.DiagnosticsHandler.start(DiagnosticsHandler.java:122)
> at org.jgroups.protocols.TP.startDiagnostics(TP.java:1031)
> at org.jgroups.protocols.TP.start(TP.java:938)
> at org.jgroups.protocols.UDP.start(UDP.java:295)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:888)
> at org.jgroups.JChannel.startStack(JChannel.java:980)
> at org.jgroups.JChannel._preConnect(JChannel.java:844)
> at org.jgroups.JChannel.connect(JChannel.java:349)
> at org.jgroups.JChannel.connect(JChannel.java:343)
> at com.thorstenmarx.webtools.cluster.JGroupsTest.simple(JGroupsTest.java:43)
> {code}
> It seems to be caused by https://stackoverflow.com/questions/14086740/how-to-create-a-new-multicas...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years