December 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5761) Update transformers & tests for EAP 6.2, 6.3 & 6.4

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFLY-5761: --------------------------------- Summary: Update transformers & tests for EAP 6.2, 6.3 & 6.4 Key: WFLY-5761 URL: https://issues.jboss.org/browse/WFLY-5761 Project: WildFly Issue Type: Task Components: Domain Management Reporter: Tomaz Cerar Assignee: Tomaz Cerar Transformers tests need to be updated to test for compatibility of: - EAP 6.2 - EAP 6.3 - EAP 6.4 And possibly also micro releases of each. But that should be handled as separate task. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-977) Error in combining str[contains] with OR results

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-977?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-977. -------------------------------- Resolution: Out of Date The problem is not caused by OR. We never had a str[contains] operator. Only supported operators are startsWith, endsWith and length. However the str[] operators are legacy stuff that has been introduced when Drools didn't have free form expressions. For this reason they have to be considered deprecated. Instead of them use the native methods of the java.lang.String object and then instead of name str[contains] "test1" just write name.contains( "test1" ) > Error in combining str[contains] with OR results > ------------------------------------------------ > > Key: DROOLS-977 > URL: https://issues.jboss.org/browse/DROOLS-977 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Environment: CentOS 6.4, WildFly > Reporter: hoon lee > Assignee: Mario Fusco > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4608) Omit no-op transaction if lifecycle method is missing

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-4608?page=com.atlassian.jira.plugin.... ] Ivo Studensky closed WFLY-4608. ------------------------------- Resolution: Won't Fix > Omit no-op transaction if lifecycle method is missing > ----------------------------------------------------- > > Key: WFLY-4608 > URL: https://issues.jboss.org/browse/WFLY-4608 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.CR1 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 10.0.0.CR5 > > > LifecycleCMTTxInterceptor creates a no-op transaction even if there is no lifecycle method defined in the bean. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4608) Omit no-op transaction if lifecycle method is missing

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-4608?page=com.atlassian.jira.plugin.... ] Ivo Studensky commented on WFLY-4608: ------------------------------------- Ok. It looks like we are fine in terms of EJB spec. As long as {{interceptorConfig}} does not cover all possible interceptor configs (like interceptors in deployment descriptors - see details in comments of the declined PR), we cannot safely avoid these no-op transactions. One issue related to this has been fixed by WFLY-4635. > Omit no-op transaction if lifecycle method is missing > ----------------------------------------------------- > > Key: WFLY-4608 > URL: https://issues.jboss.org/browse/WFLY-4608 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.CR1 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 10.0.0.CR5 > > > LifecycleCMTTxInterceptor creates a no-op transaction even if there is no lifecycle method defined in the bean. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3549) Deadlock during shutdown

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3549?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3549: ----------------------------------------------- Richa <rmarwaha(a)redhat.com> changed the Status of [bug 1184532|https://bugzilla.redhat.com/show_bug.cgi?id=1184532] from NEW to CLOSED > Deadlock during shutdown > ------------------------ > > Key: WFLY-3549 > URL: https://issues.jboss.org/browse/WFLY-3549 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: David Lloyd > Fix For: 8.2.0.Final > > > This deadlock appeared in an Arquillian test: > {noformat} > Found one Java-level deadlock: > ============================= > "undefined": > waiting to lock monitor 0x00007f67a421bfa8 (object 0x00000000e0700480, a org.jboss.as.threads.ScheduledThreadPoolService), > which is held by "MSC service thread 1-2" > "MSC service thread 1-2": > waiting for ownable synchronizer 0x00000000e0700618, (a java.util.concurrent.locks.ReentrantLock$NonfairSync), > which is held by "undefined" > Java stack information for the threads listed above: > =================================================== > "undefined": > at org.jboss.as.threads.ScheduledThreadPoolService$ExecutorImpl.terminated(ScheduledThreadPoolService.java:121) > - waiting to lock <0x00000000e0700480> (a org.jboss.as.threads.ScheduledThreadPoolService) > at java.util.concurrent.ThreadPoolExecutor.tryTerminate(ThreadPoolExecutor.java:704) > at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1006) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1163) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > "MSC service thread 1-2": > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000e0700618> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197) > at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214) > at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290) > at java.util.concurrent.ThreadPoolExecutor.interruptIdleWorkers(ThreadPoolExecutor.java:781) > at java.util.concurrent.ThreadPoolExecutor.tryTerminate(ThreadPoolExecutor.java:695) > at java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1397) > at java.util.concurrent.ScheduledThreadPoolExecutor.shutdown(ScheduledThreadPoolExecutor.java:759) > at org.jboss.as.threads.ManagedScheduledExecutorService.internalShutdown(ManagedScheduledExecutorService.java:53) > at org.jboss.as.threads.ScheduledThreadPoolService.stop(ScheduledThreadPoolService.java:67) > - locked <0x00000000e0700480> (a org.jboss.as.threads.ScheduledThreadPoolService) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) > Found 1 deadlock. > {noformat} > Looks like two MSC service threads exited and tried to terminate the thread pool at the same time. And because the MSC threads are not daemon threads, the entire JVM hangs and blocks the Arquillian test that was waiting for the container to shut down. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-954) Removal of a rule having a sub-sub-network doesn't cleanup the outermost subnetwork

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-954?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-954: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1273087|https://bugzilla.redhat.com/show_bug.cgi?id=1273087] from ON_QA to VERIFIED > Removal of a rule having a sub-sub-network doesn't cleanup the outermost subnetwork > ----------------------------------------------------------------------------------- > > Key: DROOLS-954 > URL: https://issues.jboss.org/browse/DROOLS-954 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.4.x > > > Removal of a rule having a sub-sub-network (as in the following drl) doesn't cleanup the outermost subnetwork > {code} > rule R when > $l : List() > exists Integer( this == 1 ) from $l > exists Integer( this == 2 ) from $l > then > end > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-951) Removing 2 or more rules does not retract justified objects

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-951?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-951: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1273087|https://bugzilla.redhat.com/show_bug.cgi?id=1273087] from ON_QA to VERIFIED > Removing 2 or more rules does not retract justified objects > ----------------------------------------------------------- > > Key: DROOLS-951 > URL: https://issues.jboss.org/browse/DROOLS-951 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Zvonimir Bošnjak > Assignee: Mario Fusco > Fix For: 6.4.x > > > When removing rules from knowledge which have logically inserted (justified) objects, only one object (from first removed rule) will be retracted. > In example from AddRemoveRule#184: as it removes the first rule, it re-initializes all other path memories and, in particular, marks them as unlinked (AbstractTerminalNode#204) > Later, when it tries to flush the deletions (AddRemoveRule#280), the unlinked status prevents the propagation from taking place. > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-950) Problem when a rule removal causes the merge of 2 segments and the first of the 2 haven't been initialized yet

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-950?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-950: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1273087|https://bugzilla.redhat.com/show_bug.cgi?id=1273087] from ON_QA to VERIFIED > Problem when a rule removal causes the merge of 2 segments and the first of the 2 haven't been initialized yet > -------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-950 > URL: https://issues.jboss.org/browse/DROOLS-950 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.4.x > > > When a rule removal causes the merge of 2 segments and the first of the 2 haven't been initialized yet, the merged segment only has the nodes of the second segment while the ones of the first are totally skipped. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-891) Missing alpha node removal when the only rule using it is removed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-891?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-891: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1273087|https://bugzilla.redhat.com/show_bug.cgi?id=1273087] from ON_QA to VERIFIED > Missing alpha node removal when the only rule using it is removed > ----------------------------------------------------------------- > > Key: DROOLS-891 > URL: https://issues.jboss.org/browse/DROOLS-891 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.3.0.CR2 > > > When an alpha node has more than one sink and it is used by only one rule doesn't get removed when the rule itself is removed. The following test case demonstrates the problem. > {code} > @Test > public void testRemoveHasSameConElement() { > String packageName = "test"; > String rule1 = "package " + packageName + ";" + > "import java.util.Map; \n" + > "rule 'rule1' \n" + > "when \n" + > " Map(this['type'] == 'Goods' && this['brand'] == 'a') \n" + > " Map(this['type'] == 'Goods' && this['category'] == 'b') \n" + > "then \n" + > "System.out.println('test rule 1'); \n"+ > "end"; > KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder(); > kbuilder.add( ResourceFactory.newByteArrayResource( rule1.getBytes() ), ResourceType.DRL ); > if ( kbuilder.hasErrors() ) { > fail( kbuilder.getErrors().toString() ); > } > KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(); > kbase.addKnowledgePackages( kbuilder.getKnowledgePackages() ); > kbase.removeKnowledgePackage(packageName); > StatelessKnowledgeSession session = kbase.newStatelessKnowledgeSession(); > session.execute(new HashMap()); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-801) Attempt to remove KnowledgePackage causes ClassCastException

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-801?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-801: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1273087|https://bugzilla.redhat.com/show_bug.cgi?id=1273087] from ON_QA to VERIFIED > Attempt to remove KnowledgePackage causes ClassCastException > ------------------------------------------------------------ > > Key: DROOLS-801 > URL: https://issues.jboss.org/browse/DROOLS-801 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.2.0.Final > Reporter: Tom Hartwell > Assignee: Mario Fusco > Fix For: 6.3.0.Beta2 > > Attachments: class-cast-exception-trace-log.txt, ClassCastExceptionTest.java > > > Running the JUnit attached to this issue causes a Java ClassCastException -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2015