January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-1354) Duplicate parameter while trying to use pattern bound variables or globals in accumulate function

by Eric Miles (JIRA)

Duplicate parameter while trying to use pattern bound variables or globals in accumulate function ------------------------------------------------------------------------------------------------- Key: JBRULES-1354 URL: http://jira.jboss.com/jira/browse/JBRULES-1354 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.3 Environment: JDK 1.5.0_13, Ubuntu 7.10 Reporter: Eric Miles Whenever I attempt to reference a pattern bound variable (declared outside of accumulate) or a global from within an accumulate function, I get a "Duplicate parameter" error. Example of pattern bound variable: rule "Test" when $obj: SomeObject() Integer() from accumulate( AnotherObject() , init (int total = 0 ), action ( total += $obj.getValue(); ), reverse ( total -= $obj.getValue(); ), result ( total) ) then System.out.println("HI!"); end The same happens when if I attempt to use a global. Here is an exact stacktrace of the error: org.drools.rule.InvalidRulePackage: Rule Compilation error : [Rule name=Daily Core Hours, agendaGroup=MAIN, salience=0, no-loop=false] com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java (32:1301) : Duplicate parameter $schedOut com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java (32:1330) : Duplicate parameter $schedIn com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java (41:1735) : Duplicate parameter $schedOut com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java (41:1764) : Duplicate parameter $schedIn com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java (51:2330) : Duplicate parameter $schedOut com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java (51:2359) : Duplicate parameter $schedIn com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java (58:2738) : Duplicate parameter $schedOut com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java (58:2767) : Duplicate parameter $schedIn at org.drools.rule.Package.checkValidity(Package.java:424) at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:364) at com.kronos.webta.service.smarttime.rules.maxiflex.FlowTest.setUpBeforeClass(FlowTest.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.ClassRoadie.runBefores(ClassRoadie.java:49) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:36) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

2
3
0 / 0

[JBoss JIRA] Updated: (JBMICROCONT-85) Test annotation overrides at the Invocation level in the metadata repository

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBMICROCONT-85?page=all ] Dimitris Andreadis updated JBMICROCONT-85: ------------------------------------------ Component/s: MetaData Add component. > Test annotation overrides at the Invocation level in the metadata repository > ---------------------------------------------------------------------------- > > Key: JBMICROCONT-85 > URL: http://jira.jboss.com/jira/browse/JBMICROCONT-85 > Project: JBoss MicroContainer > Issue Type: Sub-task > Components: MetaData > Reporter: Adrian Brock > Assigned To: Adrian Brock > Fix For: JBossMC-2.0.0.CR1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-5097) MessageDestinationReferenceMetaData produced by merge of annotation and xml loses information

by Scott M Stark (JIRA)

MessageDestinationReferenceMetaData produced by merge of annotation and xml loses information --------------------------------------------------------------------------------------------- Key: JBAS-5097 URL: http://jira.jboss.com/jira/browse/JBAS-5097 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment services Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossAS-5.0.0.CR1 ejb-jar.xml: <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"> <enterprise-beans> <message-driven> <ejb-name>DestBean</ejb-name> <message-destination-type>javax.jms.Queue</message-destination-type> <message-destination-link>two_ejb.jar#MsgBeanInQueue</message-destination-link> <message-destination-ref> <description>test destination</description> <message-destination-ref-name>replyQueue</message-destination-ref-name> <message-destination-type>javax.jms.Queue</message-destination-type> <message-destination-usage>Produces</message-destination-usage> <message-destination-link>two_ejb.jar#MsgBeanOutQueue</message-destination-link> </message-destination-ref> </message-driven> </enterprise-beans> </ejb-jar> with an annotated mdb like: @MessageDriven(name="DestBean") public class DestBean extends DestBeanBase implements MessageListener { @Resource(name="mdc") private MessageDrivenContext mdc; public DestBean() { super(); } public EJBContext getEJBContext() { return this.mdc; } } abstract public class DestBeanBase { public static final String test1 = "test1"; abstract public javax.ejb.EJBContext getEJBContext(); @Resource(name="qFactory") private QueueConnectionFactory qFactory; @Resource(name="replyQueue") private Queue replyQueue; public void onMessage(javax.jms.Message msg) {...} } Is producing a MessageDestinationReferenceMetaData that is missing much of the ejb-jar.xml information: MessageDestinationReferenceMetaData{ descriptions DescriptionsImpl (id=7741) id null ignoreDependency null injectionTargets Collections$SingletonSet<E> (id=7708) link null mappedName null name "replyQueue" resolvedJndiName null type "javax.jms.Queue" usage null } The merge of the annotation metadata with the descriptor metadata is losing information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-4835) TECH REVIEW: Clustering Guide - Chapter 1 - Introduction

by samson kittoli (JIRA)

TECH REVIEW: Clustering Guide - Chapter 1 - Introduction -------------------------------------------------------- Key: JBAS-4835 URL: http://jira.jboss.com/jira/browse/JBAS-4835 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Documentation Affects Versions: JBossAS-4.2.2.GA Reporter: samson kittoli Assigned To: Norman Richards Attached is an Open Office 2.0 Document containing a chapter of the Clustering Guide 1. Open document in Open Office 2. Edit -> Changes -> Record 3. Edit the document 4. Save changes and reattach to this Jira It is important for track changes to be enabled so the re-write can be easily performed. http://labs.jboss.com/jbossas/docs/Clustering_Guide/beta422/html/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

4
8
0 / 0

[JBoss JIRA] Created: (JBBUILD-324) Build.xml in testsuite directory doesn't support multiple JVM argument

by Sunny Chan (JIRA)

Build.xml in testsuite directory doesn't support multiple JVM argument ---------------------------------------------------------------------- Key: JBBUILD-324 URL: http://jira.jboss.com/jira/browse/JBBUILD-324 Project: JBoss Build System Issue Type: Feature Request Components: Targets and Tasks Affects Versions: Repository Build head, Repsository Build Branch_4_0 Environment: Any Reporter: Sunny Chan Priority: Minor We are using the JBoss unit test as part of our JVM verification testsuite. We wanted to be able to invoke tests with multiple JVM options, but it didn't work. If you set parameters via build.sh -Djunit.vm.options with multiple paramters (e.g. -Djunit.vm.options="-d64 -verbose:gc"), it will fail with unrecongized option error. The problem is that in testsuite/build.xml, the junit.vm.options is passed onto junit ant task via <jvmarg value> tag rather then <jvmarg line> tag. The jvmarg line allows multiple JVM options exist in one line. Once I replace all instance of <jvmarg value="${junit.jvm.options}"/> with <jvmarg line="${junit.jvm.options}"/> then the problem goes away. I can provide a patch for this if you want - but I don't know the rules on patches (whether I need to be cleared for contribution) so let me know if you want that. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

4
8
0 / 0

[JBoss JIRA] Updated: (JBAOP-200) Make sure the batch and sh files work

by Flavia Rainone (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-200?page=all ] Flavia Rainone updated JBAOP-200: --------------------------------- Fix Version/s: 2.0.0.CR3 (was: 2.0.0.GA) > Make sure the batch and sh files work > ------------------------------------- > > Key: JBAOP-200 > URL: http://jira.jboss.com/jira/browse/JBAOP-200 > Project: JBoss AOP > Issue Type: Bug > Reporter: Kabir Khan > Assigned To: Stale Pedersen > Fix For: 2.0.0.CR3 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAOP-200) Make sure the batch and sh files work

by Flavia Rainone (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-200?page=all ] Flavia Rainone closed JBAOP-200. -------------------------------- Resolution: Done > Make sure the batch and sh files work > ------------------------------------- > > Key: JBAOP-200 > URL: http://jira.jboss.com/jira/browse/JBAOP-200 > Project: JBoss AOP > Issue Type: Bug > Reporter: Kabir Khan > Assigned To: Stale Pedersen > Fix For: 2.0.0.CR3 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBAOP-200) Make sure the batch and sh files work

by Flavia Rainone (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-200?page=all ] Flavia Rainone reopened JBAOP-200: ---------------------------------- > Make sure the batch and sh files work > ------------------------------------- > > Key: JBAOP-200 > URL: http://jira.jboss.com/jira/browse/JBAOP-200 > Project: JBoss AOP > Issue Type: Bug > Reporter: Kabir Khan > Assigned To: Stale Pedersen > Fix For: 2.0.0.CR3 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAOP-500) Deadlock involving Interceptor Chain lock and class loading

by Flavia Rainone (JIRA)

Deadlock involving Interceptor Chain lock and class loading ----------------------------------------------------------- Key: JBAOP-500 URL: http://jira.jboss.com/jira/browse/JBAOP-500 Project: JBoss AOP Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR2 Reporter: Flavia Rainone Assigned To: Flavia Rainone Fix For: 2.0.0.GA This deadlock can be reproduced by running the rebuildingchain test (written to detect bug JBAOP-380) The scenario of this deadlock is the following: -Thread 0 (org.jboss.test.aop.rebuldingchain.SyncThread) When this thread calls the joinpoint SyncThread.checkStatus, its wrapper is executed. This wrapper needs to generate the Joinpoint class to do interception and, hence, acquires the lock for InterceptorChain read. As part of the generation fo the Joinpoint class, this class must be loaded. When the class loader loads this class, AOPTransformer is invoked. This class triggers the transformation of the class, which requires the AspectManager lock. - Thread 1 (org.jboss.test.aop.rebuildingchain.RebuildThread) This thread adds a binding to AspectManager. As part of the addBinding method execution, the AspectManager lock is acquired. As soon as the binding is addded to the bindings collection, the affect advisors have to rebuild their interceptor chains. SyncThread advisor is the affected advisor in this scenario and, to rebuild chains, it needs the write lock for the SyncThread.checkStatus inteceptor chain. This thread starts waiting for Thread0 to release the interceptor chain read lock. - Main Thread Waits for the other two threads to finish. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (JBAOP-497) ClassNotFoundException on JBoss 5

by Flavia Rainone (JIRA)

ClassNotFoundException on JBoss 5 --------------------------------- Key: JBAOP-497 URL: http://jira.jboss.com/jira/browse/JBAOP-497 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR2 Reporter: Flavia Rainone Fix For: 2.0.0.GA JBoss AOP is generating several ClassNotFoundExceptions during JBoss 5 startup. This happens when JBoss AOP tries to load annotation classes. An example of a stack trace is: at java.lang.Throwable.fillInStackTrace(Native Method) at java.lang.Throwable.<init>(Throwable.java:218) at java.lang.Exception.<init>(Exception.java:59) at java.lang.ClassNotFoundException.<init>(ClassNotFoundException.java:65) at java.lang.ClassLoader.findBootstrapClass(Native Method) at java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:891) at java.lang.ClassLoader.loadClass(ClassLoader.java:301) - locked <0x91ea0d38> (a sun.misc.Launcher$ExtClassLoader) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) - locked <0x91ea0cf0> (a sun.misc.Launcher$AppClassLoader) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) - locked <0x91ea0cf0> (a sun.misc.Launcher$AppClassLoader) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) - locked <0x91ea0d80> (a org.jboss.system.NoAnnotationURLClassLoader) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) - locked <0x91e9da68> (a org.jboss.system.NoAnnotationURLClassLoader) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.jboss.aop.Advisor.hasJoinPointAnnotationFromStringName(Advisor.java:615) at org.jboss.aop.Advisor.hasAnnotation(Advisor.java:533) at org.jboss.aop.Advisor.hasAnnotation(Advisor.java:512) at org.jboss.aop.pointcut.MethodMatcher.matchesIdentifier(MethodMatcher.java:309) at org.jboss.aop.pointcut.MethodMatcher.matches(MethodMatcher.java:106) at org.jboss.aop.pointcut.MethodMatcher.visit(MethodMatcher.java:99) at org.jboss.aop.pointcut.ast.ASTMethod.jjtAccept(ASTMethod.java:43) at org.jboss.aop.pointcut.ExecutionMethodMatcher.visit(ExecutionMethodMatcher.java:58) at org.jboss.aop.pointcut.ast.ASTExecution.jjtAccept(ASTExecution.java:37) at org.jboss.aop.pointcut.MatcherHelper.visit(MatcherHelper.java:89) at org.jboss.aop.pointcut.MatcherHelper.matches(MatcherHelper.java:83) at org.jboss.aop.pointcut.PointcutExpression.matchesExecution(PointcutExpression.java:119) at org.jboss.aop.Advisor.resolveMethodPointcut(Advisor.java:887) at org.jboss.aop.ClassContainer.createInterceptorChains(ClassContainer.java:261) - locked <0xb0127790> (a java.util.LinkedHashMap) at org.jboss.aop.ClassContainer.rebuildInterceptors(ClassContainer.java:130) at org.jboss.aop.ClassContainer.initializeClassContainer(ClassContainer.java:66) at org.jboss.aop.proxy.container.ClassProxyContainer.initialise(ClassProxyContainer.java:172) at org.jboss.aop.proxy.container.InstanceProxyContainer.<init>(InstanceProxyContainer.java:56) at org.jboss.aop.proxy.container.InstanceProxyContainer.createInstanceProxyContainer(InstanceProxyContainer.java:68) at org.jboss.aop.proxy.container.ContainerCache.initInstanceContainer(ContainerCache.java:277) at org.jboss.aop.proxy.container.ContainerCache.initialise(ContainerCache.java:93) - locked <0x91ee4b60> (a java.lang.Object) at org.jboss.aop.proxy.container.ContainerCache.initialise(ContainerCache.java:72) at org.jboss.aop.microcontainer.integration.AOPDependencyBuilder.getDependencies(AOPDependencyBuilder.java:97) - locked <0x91ee4b60> (a java.lang.Object) at org.jboss.classadapter.plugins.BasicClassAdapter.getDependencies(BasicClassAdapter.java:80) at org.jboss.beans.info.plugins.AbstractBeanInfo.getDependencies(AbstractBeanInfo.java:211) To reproduce the failure, generating one or more thread dumps during server boot is enough. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2008