January 2008 - jboss-jira - Jboss List Archives

[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

18 years, 4 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

18 years, 4 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

18 years, 4 months

1
6
0 / 0

[JBoss JIRA] Created: (JBAOP-505) Parameter Matching Backtrack can break indexes

by Flavia Rainone (JIRA)

Parameter Matching Backtrack can break indexes ---------------------------------------------- Key: JBAOP-505 URL: http://jira.jboss.com/jira/browse/JBAOP-505 Project: JBoss AOP Issue Type: Bug 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 Parameter matching algorithm in org.jboss.aop.pointcut.Util.ParameterMatcher.wildcard() method does not save the index values before performing backtrackable actions (i.e., calls to matches method). If matches method calls wildcard method again, it will use the same fields to control the index values. If it returns false to wildcard(), it will continue executing, but this time if the index values altered by the backtracked execution. -- 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

18 years, 4 months

1
5
0 / 0

[JBoss JIRA] Created: (JBRULES-1336) Typo in RuleBaseConfiguration(ClassLoader classLoder, Properties properties) -- the ClassLoader specified in the constructor args is not used

by James Sparrow (JIRA)

Typo in RuleBaseConfiguration(ClassLoader classLoder, Properties properties) -- the ClassLoader specified in the constructor args is not used --------------------------------------------------------------------------------------------------------------------------------------------- Key: JBRULES-1336 URL: http://jira.jboss.com/jira/browse/JBRULES-1336 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.3 Reporter: James Sparrow The RuleBaseConfiguration constructor: {code} public RuleBaseConfiguration(ClassLoader classLoder, Properties properties) { init( classLoader, properties ); } {code} contains a typo--the call to init should pass the (mis-spelled) classLoder, not the member field classLoader. As it is, the null member field is passed instead, resulting in the given ClassLoader instance being unused. Trivial fix: Just correct the spelling of the constructor arg name: {code} public RuleBaseConfiguration(ClassLoader classLoader, Properties properties) { init( classLoader, properties ); } {code} -- 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

18 years, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1412) ContextEntries should have cache nulled

by Mark Proctor (JIRA)

ContextEntries should have cache nulled --------------------------------------- Key: JBRULES-1412 URL: http://jira.jboss.com/jira/browse/JBRULES-1412 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 4.0.3, 4.0.2, 4.0.1, 4.0.0.GA Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 4.0.4, 4.1.0 If ContextEntries are not nulled after use this means that they will reference that object until the engine itself is GCd. For long lived engines users may be confused why their Objects are not getting GC'd, it'll look like a memory leak. So make sure all entries are nulled after use. -- 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

18 years, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1413) KnowledgeHelper should have cache reset before use.

by Mark Proctor (JIRA)

KnowledgeHelper should have cache reset before use. --------------------------------------------------- Key: JBRULES-1413 URL: http://jira.jboss.com/jira/browse/JBRULES-1413 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 4.0.3, 4.0.2, 4.0.1, 4.0.0.GA Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 4.0.4 KnowledgeHelper holds a reference to the tuple and the handle which can stop user Objects being GCd, in long running systems they may cause confusion. -- 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

18 years, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1325) OutOfMemry with the use of WorkingMemoryFileLogger

by Delbart Vincent (JIRA)

OutOfMemry with the use of WorkingMemoryFileLogger -------------------------------------------------- Key: JBRULES-1325 URL: http://jira.jboss.com/jira/browse/JBRULES-1325 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.3 Reporter: Delbart Vincent Priority: Critical Hello, In my tests of the 4.0.3, I have some : java.lang.OutOfMemoryError. So, I try a simple test with 10.000 sequential execution of 1 rule with no context and just a workingmemorylogger and I have the error : java.lang.OutOfMemoryError: Java heap space My code is : public class ExecReglesMemotyTest { private static final Reader DRL = new InputStreamReader(ExecReglesMemotyTest.class .getResourceAsStream("/rules/exemple.drl")); private static final String FICHIER_LOG = "session"; /** * @param args */ public static void main(String[] args) { try { PackageBuilder builder = new PackageBuilder(); builder.addPackageFromDrl(DRL); RuleBase ruleBase = RuleBaseFactory.newRuleBase(); ruleBase.addPackage(builder.getPackage()); for (int i = 0; i < 10000; i++) { StatefulSession session = ruleBase.newStatefulSession(); WorkingMemoryFileLogger logger = new WorkingMemoryFileLogger(session); logger.setFileName(FICHIER_LOG); session.fireAllRules(); logger.writeToDisk(); session.dispose(); } } catch (Exception e) { // TODO Auto-generated catch block e.printStackTrace(); } } } with this rule (doesn't matter): #created on: Fri Nov 09 15:48:45 CET 2007 package initPackage #list any import classes here. rule "ERG9" when then end I try this in 4.0.1, and it's working (no OutOfMemoryError) What's the problem ? thanks for any information, V. -- 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

18 years, 4 months

3
8
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1177) Wrong "in method flag" on stack after first invocation of a jca endpoint

by Cornelius Buschka (JIRA)

Wrong "in method flag" on stack after first invocation of a jca endpoint ------------------------------------------------------------------------ Key: EJBTHREE-1177 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1177 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.0 GA Reporter: Cornelius Buschka Wrong "in method flag" on stack after first invocation of a jca endpoint This is caused by MessageDrivenEnterpriseContext where IN_EJB_CREATE is pushed on the stack which is never removed and so remains as top level in method flag. Code of org.jboss.ejb.MessageDrivenEnterpriseContext, revision 57209 (line 70) public MessageDrivenEnterpriseContext(Object instance, Container con) throws Exception { super(instance, con); ctx = new MessageDrivenContextImpl(); ((MessageDrivenBean)instance).setMessageDrivenContext(ctx); try { (line 80) AllowedOperationsAssociation.pushInMethodFlag(IN_EJB_CREATE); Method ejbCreate = instance.getClass().getMethod("ejbCreate", new Class[0]); ejbCreate.invoke(instance, new Object[0]); } catch (InvocationTargetException e) { Throwable t = e.getTargetException(); if (t instanceof RuntimeException) { if (t instanceof EJBException) { throw (EJBException)t; } else { // Transform runtime exception into what a bean *should* have thrown throw new EJBException((RuntimeException)t); } } else if (t instanceof Exception) { throw (Exception)t; } else if (t instanceof Error) { throw (Error)t; } else { throw new org.jboss.util.NestedError("Unexpected Throwable", t); } } } On first delivery the MDB pool is created and the constructor of org.jboss.ejb.MessageDrivenEnterpriseContext is invoked, where IN_EJB_CREATE is pushed in line 80. As far as I can see, the flag is not popped from the stack. Possibly the complementary AllowedOperationsAssociation.popInMethodFlag() in a finally block after 106 is missing. (I checked the latest SVN revision (66439 ) of MessageDrivenEnterpriseContext and have not seen any changes in this area.) Regards Conni -- 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

18 years, 4 months

1
1
0 / 0

[JBoss JIRA] Deleted: (JBWEB-79) Support Tomcat

by Jean-Frederic Clere (JIRA)

[ http://jira.jboss.com/jira/browse/JBWEB-79?page=all ] Jean-Frederic Clere deleted JBWEB-79: ------------------------------------- > Support Tomcat > -------------- > > Key: JBWEB-79 > URL: http://jira.jboss.com/jira/browse/JBWEB-79 > Project: JBoss Web > Issue Type: Task > Security Level: Public(Everyone can see) > Environment: win2000 server > Reporter: sun hua > Assigned To: Mladen Turk > > Don't support Tomcat5.5 very well! > Example: > <%=***%> not support -- 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

18 years, 4 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 January 2008