February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4049) Consider removing Subject mixin from FIELD granularity session Pojos

by Brian Stansberry (JIRA)

Consider removing Subject mixin from FIELD granularity session Pojos -------------------------------------------------------------------- Key: JBAS-4049 URL: http://jira.jboss.com/jira/browse/JBAS-4049 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.Beta2, JBossAS-4.2.0.CR1 FIELD granularity replication uses a Subject mixin to the pojo to notify the session when an attribute is changed. Consider dropping this in place of having the CacheListener detect the cache change and notify the session (via the JBossCacheManager). Pro: 1) Simpler instrumentation. Classes instrumented a la the PojoCache examples (which don't add the Subject mixin) will work. The PojoCache examples can be the sole reference point for how to instrument classes. 2) For sure detects all changes in the pojo. Not sure if the Subject thing catches changes to collections of non-pojos. Con: Perhaps a bit slower, as the mechanism to look up and notify the session is more cumbersome. -- 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

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4067) Collection modifications do not trigger FieldBasedClusterdSession version update

by Brian Stansberry (JIRA)

Collection modifications do not trigger FieldBasedClusterdSession version update -------------------------------------------------------------------------------- Key: JBAS-4067 URL: http://jira.jboss.com/jira/browse/JBAS-4067 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Affects Versions: JBossAS-5.0.0.Beta1, JBossAS-4.0.5.GA, JBossAS-4.0.4.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: JBossAS-5.0.0.Beta2, JBossAS-4.2.0.CR1 FIELD granularity session replication relies on the AOP Subject/Observer pattern to detect changes in session attribute pojos and trigger a notification to the session object. The notification marks the session dirty, which in turn causes a replication of an updated version int for the session. Other nodes use the version int to detect if their locally cached session is out of sync with the distributed cache. Using Subject/Observer breaks down with collections. The registration of the session as Observer happens as part of the setAttribute call. But if an object is added to a collection following that call, it will not be observed. Also, the collection itself is not normally aspectized. Test case for this is FieldBasedTestCase.testCollectionModification(). Effect is not critical. The changed session content *is* replicated. The missing replication is the session version. This would only be an issue if session stickiness were not working correctly, and: 1) Session starts out on cluster node A, with last request leaving it at version, say, 5. 2) Session fails over to cluster node B. Modifications occur as described above, leaving session at version 6. 3) Session fails back over to cluster node A. Manager on A thinks its locally cached session is OK, so it doesn't read the version from the cache. Fix is to use the CacheListener to note events in the cache and mark the session dirty. Leave the Subject/Observer solution in place in case the same POJO is stored in multiple session (in which case the cache listener event would only notify a single session.) -- 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

1
2
0 / 0

[JBoss JIRA] Created: (JBESB-406) Race condition for threaded managed lifecycles

by Kevin Conner (JIRA)

Race condition for threaded managed lifecycles ---------------------------------------------- Key: JBESB-406 URL: http://jira.jboss.com/jira/browse/JBESB-406 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0 Reporter: Kevin Conner Assigned To: Kevin Conner Fix For: 4.0 Maintenance Pack 1 There is race condition in the AbstractThreadedManagedLifecycle class between the original thread and the background thread. The background thread must wait until the lifecycle state has transitioned out of the STARTING state before continuing. At present the background thread ignores this and attempts to transition into the RUNNING state as soon as it starts. This transition could fail resulting in the background thread terminating. -- 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

1
1
0 / 0

[JBoss JIRA] Deleted: (JBAS-3989) failing org.jboss.test.txiiop.test.IIOPUserTransactionStressTestCase

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3989?page=all ] Dimitris Andreadis deleted JBAS-3989: ------------------------------------- > failing org.jboss.test.txiiop.test.IIOPUserTransactionStressTestCase > -------------------------------------------------------------------- > > Key: JBAS-3989 > URL: http://jira.jboss.com/jira/browse/JBAS-3989 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Environment: Java Version 1.5.0_05 > Java Vendor Sun Microsystems Inc. > Java VM Name Java HotSpot(TM) Server VM > Java VM Version 1.5.0_05-b05 > Java VM Info mixed mode > OS Name Linux > OS Version 2.6.9-42.0.2.ELsmp > OS Arch i386 > Reporter: Dimitris Andreadis > Assigned To: Francisco Reverbel > > testUserTx Error N/A > java.lang.IllegalStateException > at org.jboss.tm.iiop.client.IIOPClientUserTransaction.commit(IIOPClientUserTransaction.java:315) > at org.jboss.test.txiiop.test.IIOPUserTransactionStressTestCase.testUserTx(IIOPUserTransactionStressTestCase.java:72) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > Caused by: org.omg.CosTransactions.NoTransaction: IDL:omg.org/CosTransactions/NoTransaction:1.0 > at org.jboss.tm.iiop.client.IIOPClientUserTransaction.getThreadLocalTerminator(IIOPClientUserTransaction.java:164) > at org.jboss.tm.iiop.client.IIOPClientUserTransaction.commit(IIOPClientUserTransaction.java:310) > ... 22 more > testTxMandatory Error CORBA TRANSACTION_REQUIRED 0 No; nested exception is: org.omg.CORBA.TRANSACTION_REQUIRED: Server-side Exception: javax.transaction.TransactionRequiredException: Transaction Required vmcid: 0x0 minor code: 0 completed: No > javax.transaction.TransactionRequiredException: CORBA TRANSACTION_REQUIRED 0 No; nested exception is: > org.omg.CORBA.TRANSACTION_REQUIRED: Server-side Exception: javax.transaction.TransactionRequiredException: Transaction Required vmcid: 0x0 minor code: 0 completed: No > at com.sun.corba.se.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:203) > at javax.rmi.CORBA.Util.mapSystemException(Util.java:67) > at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:150) > at org.jboss.test.txiiop.interfaces._StatefulSession_Stub.txMandatoryMethod(Unknown Source) > at org.jboss.test.txiiop.test.IIOPUserTransactionStressTestCase.testTxMandatory(IIOPUserTransactionStressTestCase.java:114) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.extensions.TestSetup.run(TestSetup.java:23) > Caused by: org.omg.CORBA.TRANSACTION_REQUIRED: Server-side Exception: javax.transaction.TransactionRequiredException: Transaction Required vmcid: 0x0 minor code: 0 completed: No > at java.lang.reflect.Constructor.newInstance(Constructor.java:494) > at org.jacorb.orb.SystemExceptionHelper.read(SystemExceptionHelper.java:173) > at org.jacorb.orb.ReplyReceiver.getReply(ReplyReceiver.java:325) > at org.jacorb.orb.Delegate.invoke_internal(Delegate.java:967) > at org.jacorb.orb.Delegate.invoke(Delegate.java:868) > at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:457) > at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:125) > ... 23 more > -- 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

1
0
0 / 0

[JBoss JIRA] Resolved: (EJBTHREE-560) CLONE -Referencing JAR file in persistence.xml - Still a bug and referenced duplicate issue does not exist

by Carlo de Wolf (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-560?page=all ] Carlo de Wolf resolved EJBTHREE-560. ------------------------------------ Resolution: Cannot Reproduce Bug unit test: factory > CLONE -Referencing JAR file in persistence.xml - Still a bug and referenced duplicate issue does not exist > ---------------------------------------------------------------------------------------------------------- > > Key: EJBTHREE-560 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-560 > Project: EJB 3.0 > Issue Type: Bug > Affects Versions: EJB 3.0 RC1 > Reporter: geoffm74 > Assigned To: Carlo de Wolf > Fix For: EJB 3.0 RC10 - FD > > Attachments: PersistenceUnitDeployment.diff > > > I've installed EJB3.0RC1 and the release notes states that now all persistence.xml features are implemented. So I went on trying to use the jar file referencing. > Unfortunately I found that during deployment the only place being searched for this jar file was in JBOSS_HOME/bin. I tried with absolute paths and relative - but it kept hangin on to the bin folder - probably the working folder for jboss launcher. > My jar is bundled with my ear - where should it really be to get the jar reference workin? I think the bin folder is not a proper place.... > Peter -- 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

1
0
0 / 0

[JBoss JIRA] Assigned: (EJBTHREE-560) CLONE -Referencing JAR file in persistence.xml - Still a bug and referenced duplicate issue does not exist

by Carlo de Wolf (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-560?page=all ] Carlo de Wolf reassigned EJBTHREE-560: -------------------------------------- Assignee: Carlo de Wolf > CLONE -Referencing JAR file in persistence.xml - Still a bug and referenced duplicate issue does not exist > ---------------------------------------------------------------------------------------------------------- > > Key: EJBTHREE-560 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-560 > Project: EJB 3.0 > Issue Type: Bug > Affects Versions: EJB 3.0 RC1 > Reporter: geoffm74 > Assigned To: Carlo de Wolf > Fix For: EJB 3.0 RC10 - FD > > Attachments: PersistenceUnitDeployment.diff > > > I've installed EJB3.0RC1 and the release notes states that now all persistence.xml features are implemented. So I went on trying to use the jar file referencing. > Unfortunately I found that during deployment the only place being searched for this jar file was in JBOSS_HOME/bin. I tried with absolute paths and relative - but it kept hangin on to the bin folder - probably the working folder for jboss launcher. > My jar is bundled with my ear - where should it really be to get the jar reference workin? I think the bin folder is not a proper place.... > Peter -- 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

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-946) How-To for installing/creating pojocacheable classes in JBoss 4.0.5/Cache 1.4.1/JDK5

by Jamie Reifsnyder (JIRA)

How-To for installing/creating pojocacheable classes in JBoss 4.0.5/Cache 1.4.1/JDK5 ------------------------------------------------------------------------------------ Key: JBCACHE-946 URL: http://jira.jboss.com/jira/browse/JBCACHE-946 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: PojoCache Affects Versions: 1.4.1.GA Environment: JBoss 4.0.5.GA, JBoss AOP 1.5.2.GA, JBoss Cache 1.4.1GA, JDK5 Reporter: Jamie Reifsnyder Assigned To: Ben Wang Attachments: To set up the PojoCache in JBoss 4.doc I pulled together install and compile instructions to create precompiled POJOs and an installed version of PojoCache on JBoss. For Ben Wang (requested in http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4004847#4004847 ) -- 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
3
0 / 0

(no subject)

by 78jk22hg5jk7＠fszz.com.cn

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4062) Remove use of JGroups Debugger from ClusterPartition

by Brian Stansberry (JIRA)

Remove use of JGroups Debugger from ClusterPartition ---------------------------------------------------- Key: JBAS-4062 URL: http://jira.jboss.com/jira/browse/JBAS-4062 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: JBossAS-5.0.0.Beta2 Debugger no longer exists in 2.5, so we need to get rid of it. -- 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

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4063) Remove EVENT_TRACE from cluster module

by Brian Stansberry (JIRA)

Remove EVENT_TRACE from cluster module -------------------------------------- Key: JBAS-4063 URL: http://jira.jboss.com/jira/browse/JBAS-4063 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: JBossAS-5.0.0.Beta2 Class org.javagroups.protocols.EventTrace is a utlility JGroups protocol in the AS cluster module source tree. It won't compile if JG 2.5 is used, and if the non-conforming bits are left it won't work properly with 2.4.x. I'm unaware of anyone using it, so I'm going to remove it. If the functionality is still desired, the protocol should be added to the JGroups src tree. -- 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

1
1
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 February 2007