[JBoss JIRA] (DROOLS-475) Drools condition part always use MVEL strict mode (extended classes doen't get properties of super class )
by Shailesh T (JIRA)
Shailesh T created DROOLS-475:
---------------------------------
Summary: Drools condition part always use MVEL strict mode (extended classes doen't get properties of super class )
Key: DROOLS-475
URL: https://issues.jboss.org/browse/DROOLS-475
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.1.Final
Environment: JDK 6, MVEL as default, with strict-mode set to false with file META-INF/drools.default.packagebuilder.conf with following entries
drools.dialect.default = mvel
drools.dialect.java = org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration
drools.dialect.java.compiler = ECLIPSE
drools.dialect.mvel = org.drools.compiler.rule.builder.dialect.mvel.MVELDialectConfiguration
drools.dialect.mvel.strict = false
Reporter: Shailesh T
Assignee: Mark Proctor
Priority: Critical
Even after setting MVEL strict mode to false, condition part of drools works using strict mode and can't work with Inherited getters of HashMap (Breaks lot of working rules from 5.4)
Error: [Error: unable to resolve method using strict-mode: defaultpkg.Test.Price()]
[Near : {... Price < 100 ....}]
...
t: HashMap(
Price < 11
)
..
Does work but
import java.util.HashMap;
declare HashMap
end
declare Test extends HashMap
end
t: Test(
Price<100
)
doesn't work (please see full rules in steps to reproduce)
Even condition
this["OtherPrices"]["OldPrice"] < 9
does work for Map but not for inherited Test class
(applicable but not included in sample code to reproduce issue)
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years
[JBoss JIRA] (WFLY-3310) NavigationHandler initialization is not thread-safe
by Harald Wellmann (JIRA)
Harald Wellmann created WFLY-3310:
-------------------------------------
Summary: NavigationHandler initialization is not thread-safe
Key: WFLY-3310
URL: https://issues.jboss.org/browse/WFLY-3310
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JSF
Affects Versions: 8.0.0.Final
Environment: Ubuntu 14.04, Oracle JDK 1.8.0_05
Reporter: Harald Wellmann
Assignee: Farah Juma
Running a stress test on my application with a large number of concurrent clients, I'm getting the following exception:
{noformat}
Caused by: java.lang.NullPointerException
at com.sun.faces.application.NavigationHandlerImpl$NavigationInfo.access$000(NavigationHandlerImpl.java:1364) [jsf-impl-2.2.5-jbossorg-3.jar:]
at com.sun.faces.application.NavigationHandlerImpl.getNavigationMap(NavigationHandlerImpl.java:296) [jsf-impl-2.2.5-jbossorg-3.jar:]
at com.sun.faces.application.NavigationHandlerImpl.getViewId(NavigationHandlerImpl.java:478) [jsf-impl-2.2.5-jbossorg-3.jar:]
at com.sun.faces.application.NavigationHandlerImpl.getNavigationCase(NavigationHandlerImpl.java:149) [jsf-impl-2.2.5-jbossorg-3.jar:]
at com.sun.faces.application.NavigationHandlerImpl.getNavigationCase(NavigationHandlerImpl.java:140) [jsf-impl-2.2.5-jbossorg-3.jar:]
{noformat}
This exception no longer occurs when the application has been warmed up by running a single request before going parallel.
The root cause appears to be in {{com.sun.faces.application.NavigationHandlerImpl}}:
{code}
private void createNavigationMaps() {
if (null == navigationMaps) {
NavigationMap result = null;
NavigationInfo info = null;
navigationMaps = new ConcurrentHashMap<String, NavigationInfo>();
result = new NavigationMap();
info = new NavigationInfo();
info.ruleSet = result;
navigationMaps.put(ROOT_NAVIGATION_MAP_ID, info);
}
}
{code}
The member {{this.navigationMaps}} is set *before* {{ROOT_NAVIGATION_MAP_ID}} is put into the map, so another thread may get null from {{navigationMap.get(ROOT_NAVIGATION_MAP_ID)}} in method {{getNavigationMap()}}.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years
[JBoss JIRA] (JGRP-1826) Discovery: file-based discovery protocols should not send discovery requests
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1826?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1826:
--------------------------------
To simplify discovery, MERGE2 (deprecated) uses its own protocol to discover all views in a cluster and to see if they're different. This means that the discovery code can be simplified.
> Discovery: file-based discovery protocols should not send discovery requests
> ----------------------------------------------------------------------------
>
> Key: JGRP-1826
> URL: https://issues.jboss.org/browse/JGRP-1826
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> When a node stores its information in a directory ({{FILE_PING}}, {{S3_PING}} or {{GOOGLE_PING}}), then we can optimize discovery by implementing a few things:
> * After reading all files, we send each node (represented by a file) a discovery request. That node processes the request and sends back a discovery response. This is unneeded traffic, especially with large clusters. Instead
> ** Read all files and add the information read from the files into the local caches (logical_addr_cache, UUID cache etc). This is the same as processing discovery responses from all members
> * Determine the coordinators directly from the file information. Perhaps we could even create a special file which contains information about the coordinator.
> ** This would prevent partitions from happening when starting up a large number of nodes: as long as that special file exists, nobody else will take ownership of it. When the coord leaves or crashes, we atomically replace the special file
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years
[JBoss JIRA] (DROOLS-471) Remove repository jboss-deprecated
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-471?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer commented on DROOLS-471:
-----------------------------------------------
I have done it so far.
Removing the deprecated repository I saw that in
droolsjbpm-integration/kie-remote/kie-services-remote/pom.xml
<!-- security -->
<dependency>
<groupId>javax.security</groupId>
<artifactId>jacc</artifactId>
<version>1.0</version>
<scope>provided</scope>
</dependency>
replaced by
<!-- security -->
<dependency>
<groupId>org.jboss.spec.javax.security.jacc</groupId>
<artifactId>jboss-jacc-api_1.5_spec</artifactId>
<version>1.0.0.Final</version>
<scope>provided</scope>
</dependency>
AND
kie-wb-distributions/kie-eap-integration/kie-eap-modules/kie-jboss-eap-base-modules/jboss-eap-6.1.1/javax-security-jacc-api-main/pom.xml
<!-- Custom dependencies. -->
<dependency>
<groupId>javax.security</groupId>
<artifactId>jacc</artifactId>
<version>1.0</version>
<type>jar</type>
</dependency>
<dependency>
<groupId>javax.security.jacc</groupId>
<artifactId>javax.security.jacc-api</artifactId>
<version>1.4</version>
<type>jar</type>
</dependency>
replaced by
<dependency>
<groupId>org.jboss.spec.javax.security.jacc</groupId>
<artifactId>jboss-jacc-api_1.5_spec</artifactId>
<version>1.0.0.Final</version>
<type>jar</type>
</dependency>
were the only "old" dependencies.
I have changed this locally and the build worked.
As org.jboss.spec.javax.security.jacc is specified with its version in jboss-integration-platform-parent I think the <version> tag is dispensable too.
I will inform the module owners.
> Remove repository jboss-deprecated
> ----------------------------------
>
> Key: DROOLS-471
> URL: https://issues.jboss.org/browse/DROOLS-471
> Project: Drools
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Beta2
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
>
> 1) In kie-parent-metadata's pom.xml, remove the repository jboss-deprecated:
> {code}
> <repository>
> <id>jboss-deprecated</id>
> <name>JBoss Deprecated</name>
> <url>https://repository.jboss.org/nexus/content/repositories/deprecated/</url>
> <releases>
> <enabled>true</enabled>
> <updatePolicy>never</updatePolicy>
> </releases>
> <snapshots>
> <enabled>false</enabled>
> </snapshots>
> </repository>
> {code}
> https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom....
> 2) remove your local repository
> 3) Do a mvn-all.sh -Dfull clean install
> If it works, commit the change.
> If it doesn't, make a list of dependencies that are still coming from the jboss-deprecated repository and make for each dependency a JIRA (or Bugzilla) issue calling to remove it. Tell the module owners who use those deprecated dependencies about the JIRA/BZ and ask them to remove the deprecated dependency.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years
[JBoss JIRA] (DROOLS-466) Reading Rules packaged inside jar
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-466?page=com.atlassian.jira.plugin... ]
Davide Sottara commented on DROOLS-466:
---------------------------------------
We'll investigate. Mario is the best person to answer your question, but he's on holiday and he'll be back next Monday
Davide
> Reading Rules packaged inside jar
> ---------------------------------
>
> Key: DROOLS-466
> URL: https://issues.jboss.org/browse/DROOLS-466
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Ashish Nayyar
> Assignee: Mark Proctor
> Labels: drools, drools-compiler
>
> I am working on DROOLS 6.0.1 application. I have my rule files (*.drl) packaged inside a separate project which is included as a jar file as a maven dependency. When I deploy my project, KIEModule is not able to find the rules files (which are packaged inside the jar above). I am not getting an error though but rules are not getting fired.
> If I manually place the rules files under classpath say WEB-INF/rules/*.drl they are detected and rules are executed.
> I was under impression that KIEmodules are auto discovered from anywhere in classpath.
> Any pointers are appreciated. This is general question hence I have not included the comprehensive code files. Everything start working once I place the *.drl files in the classpath (take them outside of jar).
> On Further invstigation by looking into the code, I found that
> addFiles(assets, kBaseModel, kModule);
> Call from "AbstractKieModule" fails and its not able to find the rules packaged inside the JAR file placed under WEB-INF\lib folder. I get this warning message on the console
> 08:40:02,113 WARN [org.drools.compiler.kie.builder.impl.AbstractKieModule] (ServerService Thread Pool -- 55) No files found for KieBase kie-base-old, searching folder \Apps\jboss-eap-6.1\standalone\deployments\Application.war
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years
[JBoss JIRA] (WFLY-3309) Update HAL to 2.2.4.Final
by Harald Pehl (JIRA)
Harald Pehl created WFLY-3309:
---------------------------------
Summary: Update HAL to 2.2.4.Final
Key: WFLY-3309
URL: https://issues.jboss.org/browse/WFLY-3309
Project: WildFly
Issue Type: Component Upgrade
Security Level: Public (Everyone can see)
Components: Web Console
Reporter: Harald Pehl
Assignee: Harald Pehl
Fix For: 8.1.0.Final
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years
[JBoss JIRA] (DROOLS-466) Reading Rules packaged inside jar
by Ashish Nayyar (JIRA)
[ https://issues.jboss.org/browse/DROOLS-466?page=com.atlassian.jira.plugin... ]
Ashish Nayyar commented on DROOLS-466:
--------------------------------------
Experts,
Please reply.
> Reading Rules packaged inside jar
> ---------------------------------
>
> Key: DROOLS-466
> URL: https://issues.jboss.org/browse/DROOLS-466
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Ashish Nayyar
> Assignee: Mark Proctor
> Labels: drools, drools-compiler
>
> I am working on DROOLS 6.0.1 application. I have my rule files (*.drl) packaged inside a separate project which is included as a jar file as a maven dependency. When I deploy my project, KIEModule is not able to find the rules files (which are packaged inside the jar above). I am not getting an error though but rules are not getting fired.
> If I manually place the rules files under classpath say WEB-INF/rules/*.drl they are detected and rules are executed.
> I was under impression that KIEmodules are auto discovered from anywhere in classpath.
> Any pointers are appreciated. This is general question hence I have not included the comprehensive code files. Everything start working once I place the *.drl files in the classpath (take them outside of jar).
> On Further invstigation by looking into the code, I found that
> addFiles(assets, kBaseModel, kModule);
> Call from "AbstractKieModule" fails and its not able to find the rules packaged inside the JAR file placed under WEB-INF\lib folder. I get this warning message on the console
> 08:40:02,113 WARN [org.drools.compiler.kie.builder.impl.AbstractKieModule] (ServerService Thread Pool -- 55) No files found for KieBase kie-base-old, searching folder \Apps\jboss-eap-6.1\standalone\deployments\Application.war
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years
[JBoss JIRA] (WFLY-1465) Composite operations failing with incorrect description
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-1465?page=com.atlassian.jira.plugin.... ]
James Perkins closed WFLY-1465.
-------------------------------
Resolution: Out of Date
This no longer seems to be an issue.
> Composite operations failing with incorrect description
> -------------------------------------------------------
>
> Key: WFLY-1465
> URL: https://issues.jboss.org/browse/WFLY-1465
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Attachments: configure-logging.cli
>
>
> Running the attached script will fail with the message:
> {code}
> #1 /subsystem=logging/periodic-rotating-file-handler=FILE_QS_WARN:add(suffix=".yyyy.MM.dd", file={"path"=>"quickstart.warn.log", "relative-to"=>"jboss.server.log.dir"})
> #2 /subsystem=logging/periodic-rotating-file-handler=FILE_QS_ERROR:add(suffix=".yyyy.MM.dd", file={"path"=>"quickstart.error.log", "relative-to"=>"jboss.server.log.dir"})
> #3 /subsystem=logging/periodic-rotating-file-handler=FILE_QS_INFO:add(suffix=".yyyy.MM.dd", file={"path"=>"quickstart.info.log", "relative-to"=>"jboss.server.log.dir"})
> #4 /subsystem=logging/periodic-rotating-file-handler=FILE_QS_DEBUG:add(suffix=".yyyy.MM.dd", file={"path"=>"quickstart.debug.log", "relative-to"=>"jboss.server.log.dir"})
> #5 /subsystem=logging/periodic-rotating-file-handler=FILE_QS_TRACE:add(suffix=".yyyy.MM.dd", file={"path"=>"quickstart.trace.log", "relative-to"=>"jboss.server.log.dir"})
> #6 /subsystem=logging/periodic-rotating-file-handler=FILE_QS_FATAL:add(suffix=".yyyy.MM.dd", file={"path"=>"quickstart.fatal.log", "relative-to"=>"jboss.server.log.dir"})
> #7 /subsystem=logging/async-handler=WARN_QS_ASYNC:add(level=WARN,queue-length=1024,overflow-action=BLOCK,subhandlers=["FILE_QS_WARN"])
> #8 /subsystem=logging/logger=org.jboss.as.quickstarts.logging:add(level=TRACE)
> #9 /subsystem=logging/logger=org.jboss.as.quickstarts.logging:assign-handler(name="WARN_QS_ASYNC")
> #10 /subsystem=logging/logger=org.jboss.as.quickstarts.logging:assign-handler(name="FILE_QS_ERROR")
> #11 /subsystem=logging/logger=org.jboss.as.quickstarts.logging:assign-handler(name="FILE_QS_INFO")
> #12 /subsystem=logging/logger=org.jboss.as.quickstarts.logging:assign-handler(name="FILE_QS_DEBUG")
> #13 /subsystem=logging/logger=org.jboss.as.quickstarts.logging:assign-handler(name="FILE_QS_TRACE")
> #14 /subsystem=logging/logger=org.jboss.as.quickstarts.logging:assign-handler(name="FILE_QS_FATAL")
> {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-9" => "JBAS011536: Handler FILE_QS_FATAL is already assigned."}}
> {code}
> The first issue is that it shouldn't be failing. The second issue is the handler name that failed, is not the same handler that's on the step.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years