[JBoss JIRA] (DROOLS-1078) Drools can incorrectly generate Java code to access a method on a wrong reference type for a covariant return
by Juan Carlos Garcia (JIRA)
Juan Carlos Garcia created DROOLS-1078:
------------------------------------------
Summary: Drools can incorrectly generate Java code to access a method on a wrong reference type for a covariant return
Key: DROOLS-1078
URL: https://issues.jboss.org/browse/DROOLS-1078
Project: Drools
Issue Type: Bug
Affects Versions: 6.3.0.Final, 6.2.0.Final
Reporter: Juan Carlos Garcia
Assignee: Mark Proctor
Attachments: DroolsBugDemo.zip
Drools will incorrectly generate Java code to access a method on a wrong reference type, hence resulting in a rule compilation error.
Taking the following rule as example (which is also attached),
{code}
import bug.demo.Table;
import bug.demo.Constants;
import bug.demo.Player;
import bug.demo.event.GenericEvent;
import bug.demo.api.model.Card;
rule "BuggyRule"
when
$discardCardEvent : GenericEvent(eventName=="fooEvent",
$discardedCard : Card.fromMap(getEventProperty("fooCard")),
Constants.FOO_RANK.contains($discardedCard.getRank()),
$playerIndex : slotIndex) from entry-point "foo-stream"
$table : Table($currentPlayer : getCurrentPlayer())
then
$table.addToDiscardPile($discardedCard);
$table.reset();
$currentPlayer.removeCard($discardedCard);
end
{code}
In this case when compiling the following rule, we may end up (sometimes) with compilation error:
*The method removeCard(Card) is undefined for the type TurnbasedPlayer* , when a Player type should be used in first place.
Attached is sample project to reproduce the problem, be aware that you may need to do *mvn clean test* several times until you actually trigger the problem, if you are lucky enough it will get trigger the first time you execute it.
Environment:
{code}
>mvn -version
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
Maven home: /usr/share/maven
Java version: 1.7.0_79, vendor: Oracle Corporation
Java home: /usr/lib/jvm/jdk-7-oracle-x64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.13.0-77-generic", arch: "amd64", family: "unix"
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (DROOLS-1077) [POST] /containers/{id} is outdated
by Filippe Spolti (JIRA)
Filippe Spolti created DROOLS-1077:
--------------------------------------
Summary: [POST] /containers/{id} is outdated
Key: DROOLS-1077
URL: https://issues.jboss.org/browse/DROOLS-1077
Project: Drools
Issue Type: Bug
Components: docs
Affects Versions: 6.3.0.Final
Environment: The REST URI to send the command fire-all-rules to an running container is outdated.
Using the URI described in the docs I get the following result:
{code}
2016-02-29 17:03:26 DEBUG org.apache.http.headers - http-outgoing-0 << Allow: HEAD, DELETE, GET, OPTIONS, PUT
2016-02-29 17:03:26 DEBUG org.apache.http.headers - http-outgoing-0 << Content-Type: text/html;charset=utf-8
2016-02-29 17:03:26 DEBUG org.apache.http.headers - http-outgoing-0 << Content-Length: 1022
2016-02-29 17:03:26 DEBUG org.apache.http.headers - http-outgoing-0 << Date: Mon, 29 Feb 2016 20:03:58 GMT
Exception in thread "main" java.lang.RuntimeException: Failed with HTTP error code : 405
at org.jboss.test.arquillian.ce.decisionserver.DecisionServerSecureTest.main(DecisionServerSecureTest.java:404)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
{code}
The correct URI is:
. [POST] instances/containers/{id}
After to change the REST call worked as exp
Documentation link: https://docs.jboss.org/drools/release/6.3.0.Final/drools-docs/pdf/drools-...
Item 22.6.7.
Reporter: Filippe Spolti
Assignee: Mario Fusco
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFCORE-1417) org.jboss.as.cli.scriptsupport.CLI connect methods do not properly reset the ctx upon failure making in turn checkNotConnected() to report incorrectly
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1417?page=com.atlassian.jira.plugi... ]
Tom Fonteyne updated WFCORE-1417:
---------------------------------
Steps to Reproduce:
1. Attempt to connect via CLI.connect(...)
2. Connection fails because EAP is not running yet. CLI throws "java.lang.IllegalStateException: Unable to connect to controller"
3. Attempt to connect again.
4. CLI throws exception "java.lang.IllegalStateException: Already connected to server."
This message is incorrect. No connection has been established and should you 'accept' this fact, then any subsequent action (for example sending a command) will fail
was:
1. Attempt to connect via CLI.connect(...)
2. Connection fails because EAP is not running yet. CLI throws "java.lang.IllegalStateException: Unable to connect to controller"
3. Attempt to connect again.
4. CLI throws exception "java.lang.IllegalStateException: Already connected to server."
** This message is incorrect. No connection has been established and should you 'accept' this fact, then any subsequent action (for example sending a command) will fail
> org.jboss.as.cli.scriptsupport.CLI connect methods do not properly reset the ctx upon failure making in turn checkNotConnected() to report incorrectly
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1417
> URL: https://issues.jboss.org/browse/WFCORE-1417
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.1.0.CR1
> Reporter: Tom Fonteyne
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> cli/src/main/java/org/jboss/as/cli/scriptsupport/CLI.java
> public void connect() {
> checkAlreadyConnected();
> try {
> ctx = CommandContextFactory.getInstance().newCommandContext();
> ctx.connectController();
> } catch (CliInitializationException e) {
> throw new IllegalStateException("Unable to initialize command context.", e);
> } catch (CommandLineException e) {
> throw new IllegalStateException("Unable to connect to controller.", e);
> }
> }
> also applicable to the other connects of course.
> If the connection fails in the connect method, a subsequent connect will hit:
> private void checkAlreadyConnected() {
> if (ctx != null) throw new IllegalStateException("Already connected to server.");
> }
> and will fail for the wrong reason... as while ctx !=null is true, but the connection had failed.
> ergo, upon failure in connect, the ctx should be reset to avoid this
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFLY-6297) Identify problems introduced with new JDK9 versioning scheme
by Richard Opalka (JIRA)
[ https://issues.jboss.org/browse/WFLY-6297?page=com.atlassian.jira.plugin.... ]
Richard Opalka commented on WFLY-6297:
--------------------------------------
After source code review we identified problems with new JDK9 versioning scheme in these classes:
modules/system/layers/base/org/eclipse/jdt/ecj/main/ecj-4.4.2.jar', class 'org/eclipse/jdt/internal/compiler/apt/util/EclipseFileManager', contains string [java.version]
modules/system/layers/base/org/eclipse/jdt/ecj/main/ecj-4.4.2.jar', class 'org/eclipse/jdt/internal/compiler/tool/EclipseFileManager', contains string [java.version]
modules/system/layers/base/org/apache/cxf/main/cxf-core-3.1.4.jar', class 'org/apache/cxf/common/util/ClassHelper', contains string [java.version]
modules/system/layers/base/org/jboss/log4j/logmanager/main/log4j-jboss-logmanager-1.1.2.Final.jar', class 'org/apache/log4j/helpers/Loader', contains string [java.version]
> Identify problems introduced with new JDK9 versioning scheme
> ------------------------------------------------------------
>
> Key: WFLY-6297
> URL: https://issues.jboss.org/browse/WFLY-6297
> Project: WildFly
> Issue Type: Sub-task
> Components: Build System
> Affects Versions: 10.0.0.Final
> Reporter: Richard Opalka
> Assignee: Richard Opalka
>
> JDK9 will introduce new versioning scheme described here:
> http://openjdk.java.net/projects/verona/
> We need to identify WildFly components that are realying on
> these properties.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFLY-6297) Identify problems introduced with new JDK9 versioning scheme
by Richard Opalka (JIRA)
[ https://issues.jboss.org/browse/WFLY-6297?page=com.atlassian.jira.plugin.... ]
Richard Opalka updated WFLY-6297:
---------------------------------
Comment: was deleted
(was: After source code review we identified problems with new JDK9 versioning scheme in these classes:
modules/system/layers/base/org/eclipse/jdt/ecj/main/ecj-4.4.2.jar', class 'org/eclipse/jdt/internal/compiler/apt/util/EclipseFileManager', contains string [java.version]
modules/system/layers/base/org/eclipse/jdt/ecj/main/ecj-4.4.2.jar', class 'org/eclipse/jdt/internal/compiler/tool/EclipseFileManager', contains string [java.version]
modules/system/layers/base/org/apache/cxf/main/cxf-core-3.1.4.jar', class 'org/apache/cxf/common/util/ClassHelper', contains string [java.version]
modules/system/layers/base/org/jboss/log4j/logmanager/main/log4j-jboss-logmanager-1.1.2.Final.jar', class 'org/apache/log4j/helpers/Loader', contains string [java.version])
> Identify problems introduced with new JDK9 versioning scheme
> ------------------------------------------------------------
>
> Key: WFLY-6297
> URL: https://issues.jboss.org/browse/WFLY-6297
> Project: WildFly
> Issue Type: Sub-task
> Components: Build System
> Affects Versions: 10.0.0.Final
> Reporter: Richard Opalka
> Assignee: Richard Opalka
>
> JDK9 will introduce new versioning scheme described here:
> http://openjdk.java.net/projects/verona/
> We need to identify WildFly components that are realying on
> these properties.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFLY-6283) CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6283?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-6283:
------------------------------------
Harold, when you started the app server, did you enable clustering (e.g. "/standalone.sh -c standalone-ha.xml")?
> CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6283
> URL: https://issues.jboss.org/browse/WFLY-6283
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Harold Campbell
> Assignee: Scott Marlow
>
> With second level caching enabled in a persistence unit, my application can only be deployed once without restarting wildfly. Redeployment results in this stacktrace:
> 19:06:48,764 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 87) MSC000001: Failed to start service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": org.jboss.msc.service.StartException in service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": javax.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:954)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:882)
> at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154)
> ... 7 more
> Caused by: org.infinispan.commons.CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
> at org.infinispan.interceptors.InterceptorChain.assertNotAdded(InterceptorChain.java:76)
> at org.infinispan.interceptors.InterceptorChain.addInterceptor(InterceptorChain.java:90)
> at org.infinispan.cache.impl.CacheImpl.addInterceptor(CacheImpl.java:879)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.addInterceptor(AbstractDelegatingAdvancedCache.java:65)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:184)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:133)
> at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.prepareForValidation(BaseTransactionalDataRegion.java:145)
> at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.createAccessDelegate(BaseTransactionalDataRegion.java:130)
> at org.hibernate.cache.infinispan.naturalid.NaturalIdRegionImpl.buildAccessStrategy(NaturalIdRegionImpl.java:50)
> at org.hibernate.internal.SessionFactoryImpl.determineNaturalIdRegionAccessStrategy(SessionFactoryImpl.java:600)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:339)
> at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:879)
> ... 9 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFCORE-1417) org.jboss.as.cli.scriptsupport.CLI connect methods do not properly reset the ctx upon failure making in turn checkNotConnected() to report incorrectly
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1417?page=com.atlassian.jira.plugi... ]
Tom Fonteyne edited comment on WFCORE-1417 at 3/1/16 7:54 AM:
--------------------------------------------------------------
not sure what the correct solution would be....
either for every applicable connect:
{code:java}
public void connect() {
checkAlreadyConnected();
try {
ctx = CommandContextFactory.getInstance().newCommandContext();
ctx.connectController();
} catch (CliInitializationException e) {
ctx = null;
throw new IllegalStateException("Unable to initialize command context.", e);
} catch (CommandLineException e) {
ctx = null;
throw new IllegalStateException("Unable to connect to controller.", e);
}
}
{code}
or:
{code:java}
public void terminateSession() {
try {
ctx.terminateSession();
} finally {
ctx = null;
}
}
{code}
and for every applicable connect:
{code:java}
public void connect() {
checkAlreadyConnected();
try {
ctx = CommandContextFactory.getInstance().newCommandContext();
ctx.connectController();
} catch (CliInitializationException e) {
terminateSession();
throw new IllegalStateException("Unable to initialize command context.", e);
} catch (CommandLineException e) {
terminateSession();
throw new IllegalStateException("Unable to connect to controller.", e);
}
}
{code}
was (Author: tfonteyn):
not sure what the correct solution would be....
either for every applicable connect:
public void connect() {
checkAlreadyConnected();
try {
ctx = CommandContextFactory.getInstance().newCommandContext();
ctx.connectController();
} catch (CliInitializationException e) {
ctx = null;
throw new IllegalStateException("Unable to initialize command context.", e);
} catch (CommandLineException e) {
ctx = null;
throw new IllegalStateException("Unable to connect to controller.", e);
}
}
or:
public void terminateSession() {
try {
ctx.terminateSession();
} finally {
ctx = null;
}
}
and for every applicable connect:
public void connect() {
checkAlreadyConnected();
try {
ctx = CommandContextFactory.getInstance().newCommandContext();
ctx.connectController();
} catch (CliInitializationException e) {
terminateSession();
throw new IllegalStateException("Unable to initialize command context.", e);
} catch (CommandLineException e) {
terminateSession();
throw new IllegalStateException("Unable to connect to controller.", e);
}
}
> org.jboss.as.cli.scriptsupport.CLI connect methods do not properly reset the ctx upon failure making in turn checkNotConnected() to report incorrectly
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1417
> URL: https://issues.jboss.org/browse/WFCORE-1417
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.1.0.CR1
> Reporter: Tom Fonteyne
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> cli/src/main/java/org/jboss/as/cli/scriptsupport/CLI.java
> public void connect() {
> checkAlreadyConnected();
> try {
> ctx = CommandContextFactory.getInstance().newCommandContext();
> ctx.connectController();
> } catch (CliInitializationException e) {
> throw new IllegalStateException("Unable to initialize command context.", e);
> } catch (CommandLineException e) {
> throw new IllegalStateException("Unable to connect to controller.", e);
> }
> }
> also applicable to the other connects of course.
> If the connection fails in the connect method, a subsequent connect will hit:
> private void checkAlreadyConnected() {
> if (ctx != null) throw new IllegalStateException("Already connected to server.");
> }
> and will fail for the wrong reason... as while ctx !=null is true, but the connection had failed.
> ergo, upon failure in connect, the ctx should be reset to avoid this
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFCORE-1417) org.jboss.as.cli.scriptsupport.CLI connect methods do not properly reset the ctx upon failure making in turn checkNotConnected() to report incorrectly
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1417?page=com.atlassian.jira.plugi... ]
Tom Fonteyne reassigned WFCORE-1417:
------------------------------------
Assignee: Alexey Loubyansky (was: Tom Fonteyne)
> org.jboss.as.cli.scriptsupport.CLI connect methods do not properly reset the ctx upon failure making in turn checkNotConnected() to report incorrectly
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1417
> URL: https://issues.jboss.org/browse/WFCORE-1417
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.1.0.CR1
> Reporter: Tom Fonteyne
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> cli/src/main/java/org/jboss/as/cli/scriptsupport/CLI.java
> public void connect() {
> checkAlreadyConnected();
> try {
> ctx = CommandContextFactory.getInstance().newCommandContext();
> ctx.connectController();
> } catch (CliInitializationException e) {
> throw new IllegalStateException("Unable to initialize command context.", e);
> } catch (CommandLineException e) {
> throw new IllegalStateException("Unable to connect to controller.", e);
> }
> }
> also applicable to the other connects of course.
> If the connection fails in the connect method, a subsequent connect will hit:
> private void checkAlreadyConnected() {
> if (ctx != null) throw new IllegalStateException("Already connected to server.");
> }
> and will fail for the wrong reason... as while ctx !=null is true, but the connection had failed.
> ergo, upon failure in connect, the ctx should be reset to avoid this
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months