January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-852) Call @PostActivate after failover

by Brian Stansberry (JIRA)

Call @PostActivate after failover --------------------------------- Key: EJBTHREE-852 URL: http://jira.jboss.com/jira/browse/EJBTHREE-852 Project: EJB 3.0 Issue Type: Sub-task Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry StatefulTreeCache needs to detect a failover situation and invoke the @PostActivate callback on the bean. Pulling a bean out of the cache after failover is analogous to activating it from persistent storage. It would be nice if StatefulBeanContext exposed a property the cache could use to check this. A simple transient boolean would do. -- 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, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-837) test failure - org.jboss.ejb3.test.clusteredentity.unit.EntityQueryRedeployUnitTestCase

by Len DiMaggio (JIRA)

test failure - org.jboss.ejb3.test.clusteredentity.unit.EntityQueryRedeployUnitTestCase --------------------------------------------------------------------------------------- Key: EJBTHREE-837 URL: http://jira.jboss.com/jira/browse/EJBTHREE-837 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC9 - FD Environment: [java.version: 1.5.0_08] [java.vendor: BEA Systems, Inc.] [java.vm.version: R27.1.0-109-73164-1.5.0_08-20061129-1418-linux-ia32] [java.vm.name: BEA JRockit(R)] [java.vm.info: compiled mode] [os.name: Linux] [os.arch: i386] [os.version: 2.6.9-42.0.3.ELsmp] Reporter: Len DiMaggio Priority: Minor Suite: org.jboss.ejb3.test.clusteredentity.unit.EntityQueryRedeployUnitTestCase Test: testRedeploy Type: error Exception: javax.ejb.EJBException Message: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 ava.lang.IndexOutOfBoundsException: Index: 0, Size: 0 javax.ejb.EJBException: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:69) at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83) 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.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77) at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:102) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47) 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.dynamicInvoke(StatefulContainer.java:319) at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106) at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:412) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239) at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:190) at org.jboss.remoting.Client.invoke(Client.java:525) at org.jboss.remoting.Client.invoke(Client.java:488) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:77) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateful.StatefulRemoteProxy.invoke(StatefulRemoteProxy.java:133) at $Proxy3.getBranch(Unknown Source) at org.jboss.ejb3.test.clusteredentity.unit.EntityClassloaderTestBase.queryTest(EntityClassloaderTestBase.java:253) at org.jboss.ejb3.test.clusteredentity.unit.EntityQueryRedeployUnitTestCase.testRedeploy(EntityQueryRedeployUnitTestCase.java:57) Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:546) at java.util.ArrayList.get(ArrayList.java:321) at org.jboss.ejb3.test.clusteredentity.classloader.EntityQueryTestBean.getBranchViaNamedQuery(EntityQueryTestBean.java:162) at org.jboss.ejb3.test.clusteredentity.classloader.EntityQueryTestBean.getBranch(EntityQueryTestBean.java:136) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112) at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166) at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor.invoke(ExtendedPersistenceContextPropagationInterceptor.java:57) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:46) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79) 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.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77) at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:102) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) -- 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, 4 months

3
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-849) @PrePassivate and @PostActivate callbacks not properly handled for nested SFSBS

by Brian Stansberry (JIRA)

@PrePassivate and @PostActivate callbacks not properly handled for nested SFSBS ------------------------------------------------------------------------------- Key: EJBTHREE-849 URL: http://jira.jboss.com/jira/browse/EJBTHREE-849 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC9 - Patch 1 Reporter: Brian Stansberry Fix For: EJB 3.0 RC10 - FD For nested SFSBs that do not implement a remote interface, the passivation/activation callbacks are not properly invoked. The problem is that the invocation of StatefulBeanContext.prePassivate() and postActivate() is the responsibility of the bean cache. But, for a nested SFSB without a remote interface, the cached object is not the real context, it's a proxy (ProxiedStatefulBeanContext). The real context is separately cached as a contained element of the parent bean's context. So, this kind of nested bean is actually passivated/activated as part of passivation/activation of the parent bean. The callbacks should be invoked at the same time they are invoked on the parent. Currently the callbacks are invoked when the cache decides to passivate the proxy context, but the passivation of the proxy context is meaningless -- it does not result in serializing the bean instance, so it is incorrect to invoke the callbacks. See org.jboss.ejb3.test.stateful.unit.NestedBeanUnitTestCase for a demonstration of the failure. -- 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, 4 months

2
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-846) Clustered SFSB cache does not transfer passivated sessions on startup

by Brian Stansberry (JIRA)

Clustered SFSB cache does not transfer passivated sessions on startup --------------------------------------------------------------------- Key: EJBTHREE-846 URL: http://jira.jboss.com/jira/browse/EJBTHREE-846 Project: EJB 3.0 Issue Type: Bug Components: Clustering Affects Versions: EJB 3.0 RC9 - Patch 1, EJB 3.0 RC9 - FD Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: EJB 3.0 RC10 - FD The JBoss Cache configured for SFSB replication is not configured to transfer persistent state. As a result, passivated sessions will not be transferred to a newly joining node, and thus will not be available if a failover to that node occurs. -- 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, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-850) Suppress execution of @PrePassivate and @PostActivate when ProxiedStatefulBeanContext is serialized/deserialized

by Brian Stansberry (JIRA)

Suppress execution of @PrePassivate and @PostActivate when ProxiedStatefulBeanContext is serialized/deserialized ---------------------------------------------------------------------------------------------------------------- Key: EJBTHREE-850 URL: http://jira.jboss.com/jira/browse/EJBTHREE-850 Project: EJB 3.0 Issue Type: Sub-task Reporter: Brian Stansberry Fix For: EJB 3.0 RC10 - FD See parent issue for why it is invalid to invoke the callbacks on the bean when the cache decides to passivate the proxy. StatefulCache impls could test for instanceof ProxiedStatefulBeanContext and not call prePassivate() and postActivate(), but it is probably simpler to simply turn those methods into no-ops on ProxiedStatefulBeanContext . -- 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, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-851) Invoke @PrePassivate and @PostActivate callbacks around replication

by Brian Stansberry (JIRA)

Invoke @PrePassivate and @PostActivate callbacks around replication ------------------------------------------------------------------- Key: EJBTHREE-851 URL: http://jira.jboss.com/jira/browse/EJBTHREE-851 Project: EJB 3.0 Issue Type: Task Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry These events are not currently called, and thus beans have no mechanism to do cleanup work before their state is serialized for replication. -- 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, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-707) TreeCacheProviderHook.isMinimalPutsEnabledByDefault() wrong

by Owen Taylor (JIRA)

TreeCacheProviderHook.isMinimalPutsEnabledByDefault() wrong ----------------------------------------------------------- Key: EJBTHREE-707 URL: http://jira.jboss.com/jira/browse/EJBTHREE-707 Project: EJB 3.0 Issue Type: Bug Reporter: Owen Taylor Priority: Minor org.jboss.ejb3.entity.TreeCacheProviderHook.isMinimalPutsEnabledByDefault() returns false, which means "don't check to see if values are in the cache before inserting them again", but that's a very bad setting for the TreeCache - It causes unnecessary replication between the nodes of a cluster - It tends to cause lock conflicts because the transaction putting data into the cache has to get a (briefly) get a write lock. There are hacky workarounds in the hibernate TreeCache code not to deadlock in this code, but you still get log spew. The TreeCacheProvider provided with Hibernate (no JMX integration) returns true isMinimalPutsEnabledByDefault() as it should, so I think this is just an oversight. You can of course easily work around the problem by setting the value explicitly in the hibernate properties. -- 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, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (JBXB-75) Add version info to manifest

by Thomas Diesler (JIRA)

Add version info to manifest ---------------------------- Key: JBXB-75 URL: http://jira.jboss.com/jira/browse/JBXB-75 Project: JBoss XML Binding (JBossXB) Issue Type: Task Reporter: Thomas Diesler Fix For: JBossXB-1.0 -- 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, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-145) Serialization of ManagedPropertyImpl map results in NPE due to circular reference

by Scott M Stark (JIRA)

Serialization of ManagedPropertyImpl map results in NPE due to circular reference --------------------------------------------------------------------------------- Key: JBMICROCONT-145 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-145 Project: JBoss MicroContainer Issue Type: Bug Affects Versions: JBossMC_2_0_0 Beta Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossMC_2_0_0_CR1 If one serializes a Map of ManagedProperties associated with a ManagedObject, the following NPE results when trying to unserialize the Map: java.lang.NullPointerException at org.jboss.managed.plugins.ManagedPropertyImpl.hashCode(ManagedPropertyImpl.java:259) at java.util.HashMap.put(HashMap.java:418) at java.util.HashSet.readObject(HashSet.java:279) 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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.access$300(ObjectInputStream.java:185) at java.io.ObjectInputStream$GetFieldImpl.readFields(ObjectInputStream.java:2069) at java.io.ObjectInputStream.readFields(ObjectInputStream.java:518) at org.jboss.managed.plugins.ManagedPropertyImpl.readObject(ManagedPropertyImpl.java:304) 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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at AOPContainerProxy$1.readObject(AOPContainerProxy$1.java) 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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at java.util.HashMap.readObject(HashMap.java:1067) 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 java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at org.jboss.test.AbstractTestCase.deserialize(AbstractTestCase.java:235) at org.jboss.test.managed.mock.MockTest.testManagedPropertyMapSerialization(MockTest.java:135) The problem is that following relationship results: Map -> ManagedProperty@1 -> MangedObject -> Set<ManagedProperty> -> ManagedProperty(a)1.hashCode() A ManagedProperty that is in its readObject is deserializing its MangedObject, which deserializes its Set<ManagedProperty> properties. The ManagedProperty instance in its readObject method is seen to be already deserialized, and when its added to the Set its hashCode is called, but since the name field has not been retrieved, the NPE results. -- 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, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-3891) Upgrade to JBoss Cache 1.4.1

by Dimitris Andreadis (JIRA)

Upgrade to JBoss Cache 1.4.1 ---------------------------- Key: JBAS-3891 URL: http://jira.jboss.com/jira/browse/JBAS-3891 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: JBoss Cache Reporter: Dimitris Andreadis Fix For: JBossAS-4.2.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

19 years, 5 months

4
19
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 2007