[JBoss JIRA] (WFLY-4786) Clustering integration tests fails once -Dnode0 and -Dnode1 are used
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4786?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-4786 at 1/27/16 11:51 AM:
----------------------------------------------------------------
Managed to reproduce alright. Current list of failures is:
{noformat}
CoarseWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<2ss7WTESS7lVo3Is6zP9Lq6HGLrsV7rMfbHJjIYV=node-1>
CoarseWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<Frmey6bDfZCM7e-2ScAc7AnFI6CSdk3NaaVyVZOL=node-1>
GranularWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<HqqvZ0a_ACDXWc0RDmYyCON3cEZL3h7mf1KfpO2n=node-1>
GranularWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<oqVW8pfo_r1ZeaL-zyVMaIJ40uWrOF_Xin3lKeNp=node-1>
NonDistributableTestCase.test:127 expected:<2> but was:<1>
ReplicationForNegotiationAuthenticatorTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<ia8teO0bP1vW5DM0pqEevfUE-brgUsdmBJlMnejs=node-1>
ReplicationForNegotiationAuthenticatorTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<ULQ3vjz743vvjnLJE7nLQDNTNeDJ2p02NS6qRGp0=node-1>
{noformat}
Out of total tests run: 54, Failures: 7, Errors: 0, Skipped: 3
All except for the non-distributable fail on line
org/jboss/as/test/clustering/cluster/web/ClusteredWebFailoverAbstractCase.java:164
The test logic was introduced for WFLY-2774 via commit:
c3902e26957f607983d81c7a8f3f18e358acf743
was (Author: rhusar):
Managed to reproduce alright. Current list of failures is:
{noformat}
CoarseWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<2ss7WTESS7lVo3Is6zP9Lq6HGLrsV7rMfbHJjIYV=node-1>
CoarseWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<Frmey6bDfZCM7e-2ScAc7AnFI6CSdk3NaaVyVZOL=node-1>
GranularWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<HqqvZ0a_ACDXWc0RDmYyCON3cEZL3h7mf1KfpO2n=node-1>
GranularWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<oqVW8pfo_r1ZeaL-zyVMaIJ40uWrOF_Xin3lKeNp=node-1>
NonDistributableTestCase.test:127 expected:<2> but was:<1>
ReplicationForNegotiationAuthenticatorTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<ia8teO0bP1vW5DM0pqEevfUE-brgUsdmBJlMnejs=node-1>
ReplicationForNegotiationAuthenticatorTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<ULQ3vjz743vvjnLJE7nLQDNTNeDJ2p02NS6qRGp0=node-1>
{noformat}
Out of total tests run: 54, Failures: 7, Errors: 0, Skipped: 3
All except for the non-distributable fails on line
org/jboss/as/test/clustering/cluster/web/ClusteredWebFailoverAbstractCase.java:164
which was introduced in WFLY-2774 via commit id:
c3902e26957f607983d81c7a8f3f18e358acf743
> Clustering integration tests fails once -Dnode0 and -Dnode1 are used
> --------------------------------------------------------------------
>
> Key: WFLY-4786
> URL: https://issues.jboss.org/browse/WFLY-4786
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.Alpha3
> Reporter: Petr Kremensky
> Assignee: Radoslav Husar
> Fix For: 10.0.0.Beta2
>
> Attachments: maven.logs, results.zip, testsuite.clustering.logs.zip
>
>
> Tests from wildfly-ts-integ-clustering module fails once we change default binding interfaces by -Dnode0 and -Dnode1 properties.
> See https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-as-testsuite-...
> * build 5 binds to localhost (no -Dnode*)
> * build 6 uses -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2
> Similar failures were addressed for EAP 6 by https://bugzilla.redhat.com/show_bug.cgi?id=1076015
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-4786) Clustering integration tests fails once -Dnode0 and -Dnode1 are used
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4786?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-4786 at 1/27/16 11:50 AM:
----------------------------------------------------------------
Managed to reproduce alright. Current list of failures is:
{noformat}
CoarseWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<2ss7WTESS7lVo3Is6zP9Lq6HGLrsV7rMfbHJjIYV=node-1>
CoarseWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<Frmey6bDfZCM7e-2ScAc7AnFI6CSdk3NaaVyVZOL=node-1>
GranularWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<HqqvZ0a_ACDXWc0RDmYyCON3cEZL3h7mf1KfpO2n=node-1>
GranularWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<oqVW8pfo_r1ZeaL-zyVMaIJ40uWrOF_Xin3lKeNp=node-1>
NonDistributableTestCase.test:127 expected:<2> but was:<1>
ReplicationForNegotiationAuthenticatorTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<ia8teO0bP1vW5DM0pqEevfUE-brgUsdmBJlMnejs=node-1>
ReplicationForNegotiationAuthenticatorTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<ULQ3vjz743vvjnLJE7nLQDNTNeDJ2p02NS6qRGp0=node-1>
{noformat}
Out of total tests run: 54, Failures: 7, Errors: 0, Skipped: 3
All except for the non-distributable fails on line
org/jboss/as/test/clustering/cluster/web/ClusteredWebFailoverAbstractCase.java:164
which was introduced in WFLY-2774 via commit id:
c3902e26957f607983d81c7a8f3f18e358acf743
was (Author: rhusar):
Current list of failures is:
{noformat}
CoarseWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<2ss7WTESS7lVo3Is6zP9Lq6HGLrsV7rMfbHJjIYV=node-1>
CoarseWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<Frmey6bDfZCM7e-2ScAc7AnFI6CSdk3NaaVyVZOL=node-1>
GranularWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<HqqvZ0a_ACDXWc0RDmYyCON3cEZL3h7mf1KfpO2n=node-1>
GranularWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<oqVW8pfo_r1ZeaL-zyVMaIJ40uWrOF_Xin3lKeNp=node-1>
NonDistributableTestCase.test:127 expected:<2> but was:<1>
ReplicationForNegotiationAuthenticatorTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<ia8teO0bP1vW5DM0pqEevfUE-brgUsdmBJlMnejs=node-1>
ReplicationForNegotiationAuthenticatorTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<ULQ3vjz743vvjnLJE7nLQDNTNeDJ2p02NS6qRGp0=node-1>
{noformat}
Out of total tests run: 54, Failures: 7, Errors: 0, Skipped: 3
All except for the non-distributable fails on line
org/jboss/as/test/clustering/cluster/web/ClusteredWebFailoverAbstractCase.java:164
which was introduced in WFLY-2774 via commit id:
c3902e26957f607983d81c7a8f3f18e358acf743
> Clustering integration tests fails once -Dnode0 and -Dnode1 are used
> --------------------------------------------------------------------
>
> Key: WFLY-4786
> URL: https://issues.jboss.org/browse/WFLY-4786
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.Alpha3
> Reporter: Petr Kremensky
> Assignee: Radoslav Husar
> Fix For: 10.0.0.Beta2
>
> Attachments: maven.logs, results.zip, testsuite.clustering.logs.zip
>
>
> Tests from wildfly-ts-integ-clustering module fails once we change default binding interfaces by -Dnode0 and -Dnode1 properties.
> See https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-as-testsuite-...
> * build 5 binds to localhost (no -Dnode*)
> * build 6 uses -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2
> Similar failures were addressed for EAP 6 by https://bugzilla.redhat.com/show_bug.cgi?id=1076015
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-4786) Clustering integration tests fails once -Dnode0 and -Dnode1 are used
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4786?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-4786 at 1/27/16 11:42 AM:
----------------------------------------------------------------
Current list of failures is:
{noformat}
CoarseWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<2ss7WTESS7lVo3Is6zP9Lq6HGLrsV7rMfbHJjIYV=node-1>
CoarseWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<Frmey6bDfZCM7e-2ScAc7AnFI6CSdk3NaaVyVZOL=node-1>
GranularWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<HqqvZ0a_ACDXWc0RDmYyCON3cEZL3h7mf1KfpO2n=node-1>
GranularWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<oqVW8pfo_r1ZeaL-zyVMaIJ40uWrOF_Xin3lKeNp=node-1>
NonDistributableTestCase.test:127 expected:<2> but was:<1>
ReplicationForNegotiationAuthenticatorTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<ia8teO0bP1vW5DM0pqEevfUE-brgUsdmBJlMnejs=node-1>
ReplicationForNegotiationAuthenticatorTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<ULQ3vjz743vvjnLJE7nLQDNTNeDJ2p02NS6qRGp0=node-1>
{noformat}
Out of total tests run: 54, Failures: 7, Errors: 0, Skipped: 3
All except for the non-distributable fails on line
org/jboss/as/test/clustering/cluster/web/ClusteredWebFailoverAbstractCase.java:164
which was introduced in WFLY-2774 via commit id:
c3902e26957f607983d81c7a8f3f18e358acf743
was (Author: rhusar):
Current list of failures is:
{noformat}
CoarseWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<2ss7WTESS7lVo3Is6zP9Lq6HGLrsV7rMfbHJjIYV=node-1>
CoarseWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<Frmey6bDfZCM7e-2ScAc7AnFI6CSdk3NaaVyVZOL=node-1>
GranularWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<HqqvZ0a_ACDXWc0RDmYyCON3cEZL3h7mf1KfpO2n=node-1>
GranularWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<oqVW8pfo_r1ZeaL-zyVMaIJ40uWrOF_Xin3lKeNp=node-1>
NonDistributableTestCase.test:127 expected:<2> but was:<1>
ReplicationForNegotiationAuthenticatorTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<ia8teO0bP1vW5DM0pqEevfUE-brgUsdmBJlMnejs=node-1>
ReplicationForNegotiationAuthenticatorTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<ULQ3vjz743vvjnLJE7nLQDNTNeDJ2p02NS6qRGp0=node-1>
{noformat}
Out of total tests run: 54, Failures: 7, Errors: 0, Skipped: 3
All except for the non-distrubutable fails on line
org/jboss/as/test/clustering/cluster/web/ClusteredWebFailoverAbstractCase.java:164
which was introduced in WFLY-2774 via commit id:
c3902e26957f607983d81c7a8f3f18e358acf743
> Clustering integration tests fails once -Dnode0 and -Dnode1 are used
> --------------------------------------------------------------------
>
> Key: WFLY-4786
> URL: https://issues.jboss.org/browse/WFLY-4786
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.Alpha3
> Reporter: Petr Kremensky
> Assignee: Radoslav Husar
> Fix For: 10.0.0.Beta2
>
> Attachments: maven.logs, results.zip, testsuite.clustering.logs.zip
>
>
> Tests from wildfly-ts-integ-clustering module fails once we change default binding interfaces by -Dnode0 and -Dnode1 properties.
> See https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-as-testsuite-...
> * build 5 binds to localhost (no -Dnode*)
> * build 6 uses -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2
> Similar failures were addressed for EAP 6 by https://bugzilla.redhat.com/show_bug.cgi?id=1076015
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (DROOLS-1043) Remove deprecated knowledge-api-legacy5-adapter module
by Petr Široký (JIRA)
Petr Široký created DROOLS-1043:
-----------------------------------
Summary: Remove deprecated knowledge-api-legacy5-adapter module
Key: DROOLS-1043
URL: https://issues.jboss.org/browse/DROOLS-1043
Project: Drools
Issue Type: Task
Components: core engine
Affects Versions: 6.4.0.Beta1, 6.3.0.Final
Reporter: Petr Široký
Assignee: Petr Široký
Module {{knowledge-api-legacy5-adapter}} was meant as bridge between versions 5 and 6. For 7 it should be removed as it is no longer needed and adds additional maintenance costs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (DROOLS-1008) KieServer to update container for SNAPSHOT kjar
by Andrew Collins (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1008?page=com.atlassian.jira.plugi... ]
Andrew Collins updated DROOLS-1008:
-----------------------------------
Description:
General:
When a kjar has a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup, regardless of settings.xml snapshot updatePolicy setting. Retrieving a new snapshot version is only possible through use of KieScanner.scanNow() or recycling the JVM, which will both fetch the new artifact from the remote repository and reload the kmodule in the KieServer JVM.
Steps to reproduce:
* KieServer and Business Central deployed to separate JVMs, pointing to independent maven repositories. Snapshot updatePolicy should be "always" in KieServer settings.xml.
* Deploy new kjar snapshot from Business Central to remote artifactory. (unique version "1")
* Start KieServer (verify new snapshot version is pulled from remote)
* Deploy new kjar snapnshot. (unique version "2")
Expected behavior:
* Creating a new container, or invoking updateReleaseId() on existing container will pull latest snapshot from remote artifactory.
Actual Behavior
* Creating a new container, or invoking updateReleaseId() on existing container, does not query remote artifactory for latest snapshots.
Workaround:
* Forcing a KieScanner.scanNow() will fetch new snapshot from remote artifactory.
* Or, restarting KieScanner JVM will fetch new snapshot from remote artifactory.
was:
Description of problem:
When a kjar is a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup. Retrieving a new snapshot version is only possible through use of KieScanner.scanNow(), which will both fetch the new artifact from the remote repository, and reload the kmodule in the KieServer JVM.
> KieServer to update container for SNAPSHOT kjar
> -----------------------------------------------
>
> Key: DROOLS-1008
> URL: https://issues.jboss.org/browse/DROOLS-1008
> Project: Drools
> Issue Type: Feature Request
> Components: kie server
> Affects Versions: 6.2.0.Final, 6.3.0.Final
> Reporter: Andrew Collins
> Assignee: Mario Fusco
> Attachments: snapshot_kjar_reproducer.patch
>
>
> General:
> When a kjar has a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup, regardless of settings.xml snapshot updatePolicy setting. Retrieving a new snapshot version is only possible through use of KieScanner.scanNow() or recycling the JVM, which will both fetch the new artifact from the remote repository and reload the kmodule in the KieServer JVM.
> Steps to reproduce:
> * KieServer and Business Central deployed to separate JVMs, pointing to independent maven repositories. Snapshot updatePolicy should be "always" in KieServer settings.xml.
> * Deploy new kjar snapshot from Business Central to remote artifactory. (unique version "1")
> * Start KieServer (verify new snapshot version is pulled from remote)
> * Deploy new kjar snapnshot. (unique version "2")
> Expected behavior:
> * Creating a new container, or invoking updateReleaseId() on existing container will pull latest snapshot from remote artifactory.
> Actual Behavior
> * Creating a new container, or invoking updateReleaseId() on existing container, does not query remote artifactory for latest snapshots.
> Workaround:
> * Forcing a KieScanner.scanNow() will fetch new snapshot from remote artifactory.
> * Or, restarting KieScanner JVM will fetch new snapshot from remote artifactory.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load
by Jose Cavieres (JIRA)
[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ]
Jose Cavieres reopened DROOLS-987:
----------------------------------
There is nothing bad in that code. That same code is included in both jbpm 6 books and in the JBPM project:
* This listener should be used to automatically fire rules as soon as they get activated.
* Especially useful for executing business rule tasks as part of the process.
https://github.com/droolsjbpm/jbpm/blob/6.3.x/jbpm-flow/src/main/java/org...
See lines 82-83
Anyway, the problem doesn't disappear if you eliminate the listener and use fireUntilHalt().
In order to verify that, in RulesJUnitTest.java you just have to eliminate(or /* */) the lines 90-98 and eliminate the "//" in lines 135-136:
//Disparador disp= new Disparador();
//disp.start();
Regards
> Errors in Phreak under heavy and multi threaded load
> -----------------------------------------------------
>
> Key: DROOLS-987
> URL: https://issues.jboss.org/browse/DROOLS-987
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: linux
> Java 7
> kernel 3.16
> Reporter: Jose Cavieres
> Assignee: Marco Rietveld
> Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz
>
>
> Several threads are started, each one starts 1 jbpm process containing rule(s) task(s).
> If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%.
> Aparently the setFocus method used by rule tasks is related to the problem.
> The most comon error is:
> Caused by: java.lang.NullPointerException
> at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266)
> at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361)
> at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334)
> at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
> at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358)
> at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6076) CLI deployment of WAR exploded JSF2.2 applications fails with exceptions
by Miroslav Pavleski (JIRA)
[ https://issues.jboss.org/browse/WFLY-6076?page=com.atlassian.jira.plugin.... ]
Miroslav Pavleski commented on WFLY-6076:
-----------------------------------------
The app expects its own security domain in standalone.xml:
<security-domain name="timespent.security-domain" cache-type="default">
<authentication>
<login-module code="Simple" flag="required"/>
</authentication>
</security-domain>
> CLI deployment of WAR exploded JSF2.2 applications fails with exceptions
> ------------------------------------------------------------------------
>
> Key: WFLY-6076
> URL: https://issues.jboss.org/browse/WFLY-6076
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 10.0.0.CR5
> Reporter: Miroslav Pavleski
> Assignee: Farah Juma
> Attachments: app.zip, cli.log, console.log, other_console.log
>
>
> In 9.0.2 FINAL and prior (8.1, 8.2) deploying an exploded WAR using the CLI was working fine. This kind of deployment has benefits during development as the static resources are updated on-save.
> The problem occurs probably due JSF initialization, see the attachments.
> Deployment using mvn wildfly:deploy works fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6076) CLI deployment of WAR exploded JSF2.2 applications fails with exceptions
by Miroslav Pavleski (JIRA)
[ https://issues.jboss.org/browse/WFLY-6076?page=com.atlassian.jira.plugin.... ]
Miroslav Pavleski updated WFLY-6076:
------------------------------------
Attachment: other_console.log
app.zip
> CLI deployment of WAR exploded JSF2.2 applications fails with exceptions
> ------------------------------------------------------------------------
>
> Key: WFLY-6076
> URL: https://issues.jboss.org/browse/WFLY-6076
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 10.0.0.CR5
> Reporter: Miroslav Pavleski
> Assignee: Farah Juma
> Attachments: app.zip, cli.log, console.log, other_console.log
>
>
> In 9.0.2 FINAL and prior (8.1, 8.2) deploying an exploded WAR using the CLI was working fine. This kind of deployment has benefits during development as the static resources are updated on-save.
> The problem occurs probably due JSF initialization, see the attachments.
> Deployment using mvn wildfly:deploy works fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6076) CLI deployment of WAR exploded JSF2.2 applications fails with exceptions
by Miroslav Pavleski (JIRA)
[ https://issues.jboss.org/browse/WFLY-6076?page=com.atlassian.jira.plugin.... ]
Miroslav Pavleski commented on WFLY-6076:
-----------------------------------------
I've tried to assemble stripped down version of the app (attached).
Now it doesn't even deploy with mvn wildfly:deploy on 10CR5. Deploys on 9.0.2.Final.
> CLI deployment of WAR exploded JSF2.2 applications fails with exceptions
> ------------------------------------------------------------------------
>
> Key: WFLY-6076
> URL: https://issues.jboss.org/browse/WFLY-6076
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 10.0.0.CR5
> Reporter: Miroslav Pavleski
> Assignee: Farah Juma
> Attachments: app.zip, cli.log, console.log, other_console.log
>
>
> In 9.0.2 FINAL and prior (8.1, 8.2) deploying an exploded WAR using the CLI was working fine. This kind of deployment has benefits during development as the static resources are updated on-save.
> The problem occurs probably due JSF initialization, see the attachments.
> Deployment using mvn wildfly:deploy works fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months