March 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-660) Inline JCI and remove uneeded dependencies

by Mark Proctor (JIRA)

Inline JCI and remove uneeded dependencies ------------------------------------------ Key: JBRULES-660 URL: http://jira.jboss.com/jira/browse/JBRULES-660 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: All Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m1 Inline JCI and strip all uneeded dependencies, like collections, lang, io and logger. -- 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

19 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-449) Logical dependency bug, justifier tuple contains retracted handles, logically depend object stays in working memory

by Juergen none (JIRA)

Logical dependency bug, justifier tuple contains retracted handles, logically depend object stays in working memory ------------------------------------------------------------------------------------------------------------------- Key: JBRULES-449 URL: http://jira.jboss.com/jira/browse/JBRULES-449 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 3.0.4 Environment: jdk 1.4.2_10 Reporter: Juergen none Assigned To: Mark Proctor A rather complicated, intertwined set of rules leads to a logically asserted fact, that remains in working memory, even after its justifiers have been retracted. Sadly I have no unit-test, but I can outline the rules and execution sequence as reported by a listener (a ... assert, al ... assert logical, r ... retract) Its a buggy (R5 twice) implementation of a accumulating set of rules I posted in the user list some time ago. FFF(A), FFF(B) are of same class but not equal, @... is systemHashCode, so different instances, but possible equal (as mentioned) classes without @ have only one instance in working memory a XXX R0: XXX -> al DDD a AAA (external assert) Sequence of rules fired R1: AAA -> al GGG R2: DDD, GGG -> al CCC R3: GGG -> al EEE R4: EEE, DDD, CCC -> a BBB@15737ca, al FFF@b2d75c(A) (BBB@15737ca contributes to hash/equals of FFF@b2d75c) R5: BBB, CCC, FFF(A), not FFF(B) -> mod CCC (hashcodes changes, but all rules are still fulfilled as before), a FFF@b274de(B) R5 again (modify triggered): EEE, DDD, CCC -> a BBB@16d8ba (but equals(BBB@15737ca) is true), (+ my guess, object created and assert called but no listener info: al FFF@2aefe3(A) (equals FFF@b2d75c, backing its logical dependency) (BBB@16d8ba contributes to Hash/equals)) --- r AAA (external retract) -> (according to listener): r AAA r GGG r EEE r CCC breakpoint, screenshot --> justifier list is invalid, contains retracted handles PoolCondition would be DDD, the only valid handle in the (EEE, DDD, CCC) tuple r XXX (retract of XXX has no consequence, just the last handle, still valid in the screenshot, becomes invalid too) -> r XXX r DDD workingMemory.getObjects() lists FFF@b2d75c(A) and FFF@b274de(B) for Rulebase-properties: - RuleBaseConfiguration.PROPERTY_ASSERT_BEHAVIOR -> RuleBaseConfiguration.WM_BEHAVIOR_IDENTITY - empty Major lead could be that after commenting out "mod CCC", FFF(A) is retracted (+ R5 not fired a second time) + problem with changed hashcode of CCC ? + problem with second instances of BBB and FFF(A) being asserted + FFF(B) being assert normally, not logically -- 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

19 years, 2 months

4
12
0 / 0

[JBoss JIRA] Created: (JBRULES-722) NullPointerException when using inserAfter method with an empty LinkedList

by Pierre Paysant-Le Roux (JIRA)

NullPointerException when using inserAfter method with an empty LinkedList -------------------------------------------------------------------------- Key: JBRULES-722 URL: http://jira.jboss.com/jira/browse/JBRULES-722 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.1-m1 Environment: Windows, jdk 1.5 Reporter: Pierre Paysant-Le Roux Assigned To: Mark Proctor JBoss rules throws a NullPointerException when adding my rules file. The problem is with the inserAfter methode in LinkedList. Debug shows that it appends when inserting a node in an empty list. I wrote a simple test case to illustrate the problem : Index: drools-core/src/test/java/org/drools/util/LinkedListTest.java =================================================================== --- drools-core/src/test/java/org/drools/util/LinkedListTest.java (revision 9968) +++ drools-core/src/test/java/org/drools/util/LinkedListTest.java (working copy) @@ -264,4 +264,7 @@ 3 ); } -} \ No newline at end of file + public void testInsertAfter(){ + this.list.insertAfter( null, this.node1 ); + } +} And a patch to avoid the problem : Index: drools-core/src/main/java/org/drools/util/LinkedList.java =================================================================== --- drools-core/src/main/java/org/drools/util/LinkedList.java (revision 9968) +++ drools-core/src/main/java/org/drools/util/LinkedList.java (working copy) @@ -151,17 +151,21 @@ } if ( existingNode == null ) { - // if existing node is null, then insert it as a first node - final LinkedListNode node = this.firstNode; - node.setPrevious( newNode ); - newNode.setNext( node ); - this.firstNode = newNode; + if(this.isEmpty()) + this.add(newNode); + else{ + // if existing node is null, then insert it as a first node + final LinkedListNode node = this.firstNode; + node.setPrevious( newNode ); + newNode.setNext( node ); + this.firstNode = newNode; + } } else if ( existingNode == this.lastNode ) { existingNode.setNext(newNode); newNode.setPrevious( existingNode ); this.lastNode = newNode; } else { - ((LinkedListNode)existingNode.getNext()).setPrevious( newNode ); + ((LinkedListNode)existingNode.getNext()).setPrevious( newNode ); newNode.setNext( existingNode.getNext() ); existingNode.setNext( newNode ); newNode.setPrevious( existingNode ); Excuse me if I'm wrong. -- 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

19 years, 2 months

2
5
0 / 0

[JBoss JIRA] Created: (JBTM-207) Contention in TransactionReaper

by Phillip Thurmond (JIRA)

Contention in TransactionReaper ------------------------------- Key: JBTM-207 URL: http://jira.jboss.com/jira/browse/JBTM-207 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.2 Environment: Linux, JDK 5 Reporter: Phillip Thurmond Assigned To: Mark Little Under heavy load I am seeing a lot of contention on the TransactionReaper object. The remove() method has a large synchronized block. Could this synchronization be decreased or made to be more fine-grained? Stack trace: "http-10.68.0.196-8080-247" daemon prio=1 tid=0x0000002af2b7b030 nid=0x351a waiting for monitor entry [0x000000005a95a000..0x000000005a95cb30] at com.arjuna.ats.arjuna.coordinator.TransactionReaper.remove(TransactionReaper.java:318) - waiting to lock <0x0000002aa7dc7248> (a com.arjuna.ats.arjuna.coordinator.TransactionReaper) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:185) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1204) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:135) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:87) at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:175) at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87) at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateful.StatefulInstanceInterceptor.invoke(StatefulInstanceInterceptor.java:83) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.remoting.ReplicantsManagerInterceptor.invoke(ReplicantsManagerInterceptor.java:51) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77) at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:105) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateful.StatefulContainer.localInvoke(StatefulContainer.java:204) at org.jboss.ejb3.stateful.StatefulLocalProxy.invoke(StatefulLocalProxy.java:100) at $Proxy109.update(Unknown Source) at TodoDaoInt$$FastClassByCGLIB$$6f227f03.invoke(<generated>) at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149) at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:45) at org.jboss.seam.intercept.ClientSideInterceptor$1.proceed(ClientSideInterceptor.java:74) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:55) at org.jboss.seam.interceptors.RemoveInterceptor.removeIfNecessary(RemoveInterceptor.java:40) at sun.reflect.GeneratedMethodAccessor362.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.seam.util.Reflections.invoke(Reflections.java:18) at org.jboss.seam.intercept.Interceptor.aroundInvoke(Interceptor.java:169) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:64) at org.jboss.seam.intercept.RootInterceptor.createSeamInvocationContext(RootInterceptor.java:144) at org.jboss.seam.intercept.RootInterceptor.invokeInContexts(RootInterceptor.java:129) at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:102) at org.jboss.seam.intercept.ClientSideInterceptor.interceptInvocation(ClientSideInterceptor.java:83) at org.jboss.seam.intercept.ClientSideInterceptor.intercept(ClientSideInterceptor.java:52) at org.jboss.seam.intercept.Proxy$$EnhancerByCGLIB$$e1e24e7.update(<generated>) at sun.reflect.GeneratedMethodAccessor422.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.el.parser.AstValue.invoke(AstValue.java:131) at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) at com.sun.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:68) at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:77) at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:95) at javax.faces.component.UICommand.broadcast(UICommand.java:383) at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:448) -- 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

19 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-964) Optional 1.x marshalling for CacheLoaders using VersionAwareMarshaller

by Galder Zamarreno (JIRA)

Optional 1.x marshalling for CacheLoaders using VersionAwareMarshaller ---------------------------------------------------------------------- Key: JBCACHE-964 URL: http://jira.jboss.com/jira/browse/JBCACHE-964 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: Cache loaders Reporter: Galder Zamarreno Assigned To: Galder Zamarreno Priority: Minor Fix For: 2.0.0.BETA2, 2.0.0.GA Customers that want to use JBossCache 2.x might be reluctant to migrate their data from one format to the other. I can see how an existing customer might think this is a proper pain in the ass, independent of the benefits, and might reduce adoption among them. We want to remove barriers upgrading, but at the same time, we want new customer to use new marshalling, so I'd actually implement the possibility to use 1.x marshalling which is plan java serialization at the CacheLoader level. This could easily achieved adding a property to the <properties> section. The default in 2.x should be to use VAM and only people who are resilient to change their existing stores to VAM should use the 1.x option, which would need explicitly definition. This option also makes it easier for migration purpouses as customers should be able to start two cache instances with different cache loader marshalling method set. They could then loop through the first one using get operations and call put in the second instance. Just note that this does not apply to the marshalling done at replication level as there's no hard data that needs migrating. -- 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

19 years, 2 months

3
13
0 / 0

[JBoss JIRA] Created: (JBFORUMS-198) when I delete an user I have NullPointerException

by Luca Stancapiano (JIRA)

when I delete an user I have NullPointerException ------------------------------------------------- Key: JBFORUMS-198 URL: http://jira.jboss.com/jira/browse/JBFORUMS-198 Project: JBoss Forums Issue Type: Bug Components: Forum Model Layer Affects Versions: 1.2.0 Alpha Environment: any Reporter: Luca Stancapiano Assigned To: Ryszard Kozmik Fix For: 1.2.0 Alpha hi julien.......I tried to delete an user that is in posts of jboss forum.....after I deleted this user, if I click on posts where that user had posted I have NullPointerException I thought to correct this bug , using a UserNA object that implements User interface. This UserNA is used when I select the user from database and I haven't returned rows because user is deleted. In this case I add UserNA to User object of Post object. UserNA is declared in ForumPortlet object as final static , so the same object can to be used for each deleted user. What do you mean about it? I send you the patch -- 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

19 years, 3 months

3
6
0 / 0

[JBoss JIRA] Created: (JBBUILD-337) Change the JBoss Common Maven build scripts so that they use an inheritance model, and add JBossRetro

by Paul Gier (JIRA)

Change the JBoss Common Maven build scripts so that they use an inheritance model, and add JBossRetro ----------------------------------------------------------------------------------------------------- Key: JBBUILD-337 URL: http://jira.jboss.com/jira/browse/JBBUILD-337 Project: JBoss Build System Issue Type: Feature Request Components: Maven Reporter: Paul Gier Assigned To: Paul Gier The plugin configuration can be moved to the main build pom. Also the jar plugin should be changed to specify a minimum version of 2.1 so that the configuration parameters will always work. JBoss retro should also be called using the antrun plugin. -- 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

19 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-885) Connecting to two JBoss messaging servers causes interference

by Ben Anderson (JIRA)

Connecting to two JBoss messaging servers causes interference ------------------------------------------------------------- Key: JBMESSAGING-885 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-885 Project: JBoss Messaging Issue Type: Bug Components: JMS Client Manager Affects Versions: 1.0.1.SP4 Environment: Windows XP, Java 1.4.2-b28, JBoss 4.0.4.GA, Pentium 4 2GB RAM Reporter: Ben Anderson Assigned To: Ovidiu Feodorov When connected to two JBoss messaging servers, shutting down one server can affect (i.e. stop) the message listeners connected to the other server. -- 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

19 years, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (JBTM-195) Unexpected exception thrown with single readonly participant

by Kevin Conner (JIRA)

Unexpected exception thrown with single readonly participant ------------------------------------------------------------ Key: JBTM-195 URL: http://jira.jboss.com/jira/browse/JBTM-195 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: WS-T Implementation Affects Versions: 4.2.2 Reporter: Kevin Conner Assigned To: Kevin Conner An AT transaction with a single readonly participant results in an unexpected exception being through from the completion client. More details can be found in the associated forum entry. -- 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

19 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBTM-189) transaction manager is not properly closing connections on slave server when slave server has exceptions.

by Quande Ren (JIRA)

transaction manager is not properly closing connections on slave server when slave server has exceptions. --------------------------------------------------------------------------------------------------------- Key: JBTM-189 URL: http://jira.jboss.com/jira/browse/JBTM-189 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTS Implementation Environment: JBossAS4.0.5, JBossTS4.2.2, multiple servers, distributed transactions. Reporter: Quande Ren Assigned To: Mark Little Priority: Critical This is fully discussed at the forum: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=97856 I am using JBoss4.0.5.GA and JBossTS4.2.2. I have a ServerA and ServerB and a client. here is my flow senario: Code: 1. client call a stateless session BeanA on ServerA, 2. BeanA do some pre work, 3. BeanA then call another stateless session BeanB on serverB, 4. BeanB do some work, 5. BeanA do some post work. the result shows that if either step 2 or step 5 failed, then the whole transaction get rollbacked correctly. but if step 4 failed, then transaction on ServerA rollback, but the transaction on ServerB does not get rollbacked or committed, we can see the debug information says the xa datasource transaction get started but never get rollbacked. and the database connection remains in use, and when we run the test several times, all the database connections will used up. -- 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

19 years, 3 months

4
5
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 March 2007