September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-662) sfsb bean remove is not properly done

by Ben Wang (JIRA)

sfsb bean remove is not properly done -------------------------------------- Key: EJBTHREE-662 URL: http://jira.jboss.com/jira/browse/EJBTHREE-662 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC8 - FD Reporter: Ben Wang Assigned To: Ben Wang Fix For: EJB 3.0 RC9 - FD Currently in StatefulRemoveInterceptor, when user calls @Remove, it removes directly the bean instance in the cache. However, this is incorrect when there is nested bean involved. Correct procedure is to do StatefulBeanContext.remove() that will remove it recursively. -- 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: (EJBTHREE-659) SFSB throws exception with second passivation

by Ben Wang (JIRA)

SFSB throws exception with second passivation --------------------------------------------- Key: EJBTHREE-659 URL: http://jira.jboss.com/jira/browse/EJBTHREE-659 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC8 - FD Reporter: Ben Wang Assigned To: Ben Wang Fix For: EJB 3.0 RC9 - FD I have created a test case to illustrate this for both SimpleStatefulCache and StatefulTreeCache, NestedBeanUnitTestCase (cache and clusteredsession). Basically, if we do this: bean.getXXX sleep(10000); // to passivate bean.getXXX; // to acitvate sleep(10000); // to passivate again This will produce: 2006-07-24 04:46:59,358 ERROR [org.jboss.ejb3.cache.simple.SimpleStatefulCache] problem passivation thread^M javax.ejb.EJBException: Could not passivate; failed to save state^M at org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager.passivateSession(StatefulSessionFilePersistenceManager.java:363)^M at org.jboss.ejb3.cache.simple.SimpleStatefulCache.passivate(SimpleStatefulCache.java:196)^M at org.jboss.ejb3.cache.simple.SimpleStatefulCache$SessionTimeoutTask.run(SimpleStatefulCache.java:129)^M Caused by: java.lang.NullPointerException^M at org.jboss.serial.util.StringUtil.calculateUTFSize(StringUtil.java:319)^M at org.jboss.serial.util.StringUtil.saveString(StringUtil.java:63)^M at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput.writeUTF(DataContainer.java:265)^M at org.jboss.ejb3.stateful.StatefulBeanContextReference.writeExternal(StatefulBeanContextReference.java:65)^M at org.jboss.serial.persister.ExternalizePersister.writeData(ExternalizePersister.java:58)^M at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:275)^M at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput.writeObject(DataContainer.java:197)^M at org.jboss.serial.io.JBossObjectOutputStream.writeObjectOverride(JBossObjectOutputStream.java:181)^M at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:287)^M at org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager.passivateSession(StatefulSessionFilePersistenceManager.java:347)^M ... 2 more^M This is caused by a bug from ProxiedStatefuleBeanContext serialization where we dont serialiaze parentRef if it is not null. -- 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: (EJBTHREE-660) Nested sfsb passivation notification is incorrect

by Ben Wang (JIRA)

Nested sfsb passivation notification is incorrect ------------------------------------------------- Key: EJBTHREE-660 URL: http://jira.jboss.com/jira/browse/EJBTHREE-660 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC8 - FD Reporter: Ben Wang Assigned To: Ben Wang Fix For: EJB 3.0 RC9 - FD Current sfsb activation/passivation notification relies on read/writeExternal. This is semnatically not correct since replication also relies on serialization. So each replication would trigger a activation/passivation pair. I don't believe ejb3 specifies specifically activation/passivation to serialization (there is no word on how to perform passivation actually). So a better way is to decouple this. -- 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: (EJBTHREE-653) No pooling for stateless session beans

by Guido Bening (JIRA)

No pooling for stateless session beans -------------------------------------- Key: EJBTHREE-653 URL: http://jira.jboss.com/jira/browse/EJBTHREE-653 Project: EJB 3.0 Issue Type: Bug Components: EJB3 Extensions Affects Versions: EJB 3.0 RC8 - FD Environment: OS: Windows XP SP2 JDK 1.5.0_06_b05 JBoss AS 4.0.4 GA Reporter: Guido Bening Scenario: Client VM calls a method on a EJB 2 Stateful Session Bean (SFSB) via the remote interface in a loop for 1000 times.Transaction starts on the application server. The SFSB method calls a method on a EJB3 Stateless Session Bean (SLSB) - via the remote interface (local interface makes no difference). The print out in the PostConstruct callback method of the EJB3 SLSB shows us, that a new bean instance was created for each of the 1000 method calls. Because of ThreadLocal pooling approach, we print out the Thread id too to show, that we always have the same Thread for each method call. CallBack method: /** * EJBCreate method. */ @PostConstruct public void ejb3Create() { System.out.println("New SessionBean " + this); System.out.println("Thread " + Thread.currentThread().getId()); setupBean(); } And the log for a few of the 1000 calls: ... 09:17:51,119 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@231ae2 09:17:51,129 INFO [STDOUT] Thread 97 09:17:51,139 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@1662174 09:17:51,139 INFO [STDOUT] Thread 97 09:17:51,219 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@189f155 09:17:51,219 INFO [STDOUT] Thread 97 09:17:51,239 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@1a82dfb 09:17:51,239 INFO [STDOUT] Thread 97 09:17:51,289 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@198813a 09:17:51,289 INFO [STDOUT] Thread 97 09:17:51,309 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@59eefd 09:17:51,309 INFO [STDOUT] Thread 97 09:17:51,359 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@2e3520 09:17:51,369 INFO [STDOUT] Thread 97 09:17:51,379 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@1ed457 09:17:51,379 INFO [STDOUT] Thread 97 09:17:51,439 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@1e1c7f3 09:17:51,439 INFO [STDOUT] Thread 97 09:17:51,449 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@15cb8ed 09:17:51,449 INFO [STDOUT] Thread 97 09:17:51,519 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@1a4a949 09:17:51,519 INFO [STDOUT] Thread 97 09:17:51,529 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@19ae0a 09:17:51,529 INFO [STDOUT] Thread 97 09:17:51,589 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@567fa0 09:17:51,599 INFO [STDOUT] Thread 97 09:17:51,609 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@19956fe 09:17:51,609 INFO [STDOUT] Thread 97 09:17:51,659 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@150e574 09:17:51,669 INFO [STDOUT] Thread 97 09:17:51,679 INFO [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3@aa46ad 09:17:51,679 INFO [STDOUT] Thread 97 ... -- 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
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-650) javax.ejb.SessionContext.getInvokedBusinessInterface() has wrong return type

by Carlo de Wolf (JIRA)

javax.ejb.SessionContext.getInvokedBusinessInterface() has wrong return type ---------------------------------------------------------------------------- Key: EJBTHREE-650 URL: http://jira.jboss.com/jira/browse/EJBTHREE-650 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC8 - FD Reporter: Carlo de Wolf javax.ejb.SessionContext.getInvokedBusinessInterface() must return Class not Object. See http://java.sun.com/javaee/5/docs/api/javax/ejb/SessionContext.html#getIn... -- 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: (JBAS-3537) Add a startup switch to configure a multicast port

by Brian Stansberry (JIRA)

Add a startup switch to configure a multicast port -------------------------------------------------- Key: JBAS-3537 URL: http://jira.jboss.com/jira/browse/JBAS-3537 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.CR1 Proper cluster isolation with UDP requires use of a different cluster name, different multicast address and different multicast port. (See http://wiki.jboss.org/wiki/Wiki.jsp?page=PromiscuousTraffic for why the latter is important.) The -g and -u switches allow easy configuration of the cluster name and multicast address. But, configuring the port that way wasn't practical, as an AS instance may have many different JChannels. With the JGroups multiplexer, a switch is a possibility, as by default there will only be one JChannel per server instance. (If a user wanted to use more than one JChannel, they would need to manually configure the second one to use a different port.) -- 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
1
0 / 0

[JBoss JIRA] Created: (JBAS-3550) JBAS 4.0.4GA Test suite Error on Java 1.5 - org.jboss.test.classloader.test.CircularityUnitTestCase (testRecursiveLoadMT)

by Vivek Lakshmanan (JIRA)

JBAS 4.0.4GA Test suite Error on Java 1.5 - org.jboss.test.classloader.test.CircularityUnitTestCase (testRecursiveLoadMT) ------------------------------------------------------------------------------------------------------------------------- Key: JBAS-3550 URL: http://jira.jboss.com/jira/browse/JBAS-3550 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Test Suite Affects Versions: JBossAS-4.0.4.GA Environment: Sun 1.5.0_08, Java VM Version 1.5.0_08-b03 OS: Linux RHEL 4 U3 2.6.9-34.EL Arch: i386 Reporter: Vivek Lakshmanan The above test case seems to produce an error frequently on Sun 1.5 JVM. From a cursory search through JIRA, it seems this could be related to JIRA issue JBAS-760. The stacktrace produced in the test reports follows: javax.management.MBeanException at org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:180) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:163) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.Exception: Thread1 failed to load HARMIServerImpl_Stub, class=null at org.jboss.test.classloader.circularity.test.RecursiveCCETests.testRecursiveLoadMT(RecursiveCCETests.java:99) at org.jboss.test.classloader.circularity.Starter.testRecursiveLoadMT(Starter.java:154) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) ... 40 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, 2 months

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-3548) RMIAdaptorUnitTestCase testMBeanInfoMarshalling failures

by Matt Wringe (JIRA)

RMIAdaptorUnitTestCase testMBeanInfoMarshalling failures -------------------------------------------------------- Key: JBAS-3548 URL: http://jira.jboss.com/jira/browse/JBAS-3548 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Test Suite Affects Versions: JBossAS-4.0.4.GA Environment: Sun 1.5.0_08 JVM RHEL 4, Linux Kernel 2.6.9 Reporter: Matt Wringe The org.jboss.test.jmx.test.RMIAdaptorUnitTestCase testMBeanInfoMarshalling test fails on the Sun 1.5.0 JVM. >From the test report: "Failed to get MBeanInfo for bean named: jboss.deployment:type=DeploymentScanner,flavor=URL junit.framework.AssertionFailedError: Failed to get MBeanInfo for bean named: jboss.deployment:type=DeploymentScanner,flavor=URL at org.jboss.test.jmx.test.RMIAdaptorUnitTestCase.testMBeanInfoMarshalling(RMIAdaptorUnitTestCase.java:72)" -- 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: (JBPM-705) Provide monitoring for standalone applications

by Ryan Campbell (JIRA)

Provide monitoring for standalone applications ---------------------------------------------- Key: JBPM-705 URL: http://jira.jboss.com/jira/browse/JBPM-705 Project: JBoss jBPM Issue Type: Feature Request Reporter: Ryan Campbell Assigned To: Tom Baeyens Fix For: jBPM 3.2 Provide jmx interfaces for monitor processes not in a webapp. Or can you point the monitoring webapp at a jBPM datastore? -- 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
8
0 / 0

[JBoss JIRA] Created: (JBPM-742) Reimplement JbpmThreadsServlet as a ServletContextListener

by Alejandro Guizar (JIRA)

Reimplement JbpmThreadsServlet as a ServletContextListener ---------------------------------------------------------- Key: JBPM-742 URL: http://jira.jboss.com/jira/browse/JBPM-742 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Affects Versions: jBPM 3.1.1 Reporter: Alejandro Guizar ServletContextListeners are a viable alternative to servlets for management of the jBPM scheduler/command threads. From the Servlet 2.4 spec, section 10.2: >>> Servlet event listeners support event notifications for state changes in the ServletContext, HttpSession and ServletRequest objects. Servlet context listeners are used to **manage resources** or state held at a JVM level for the application. <<< Their intent definitely seems to match our purposes. Further below: >>> There may be multiple listener classes listening to each event type. <<< We could have separate listeners for the scheduler and command executor so that applications may remove either of them in case the related service is not used. Section 10.2.2 provides an example. When the application starts up, the listener creates a connection to the database and stores it in the servlet context. Servlets access the connection from the context as needed. When the application shuts down, the listener closes the connection. Our listener could start the thread and store it in the servlet context, then stop it using the mechanisms provided by JBPM-741. -- 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2006