[JBoss JIRA] Created: (EJBTHREE-657) StatefulBean passivation is broken (ClassCastException in org.jboss.ejb3.stateful.NestedStatefulBeanContext)
by Carlo de Wolf (JIRA)
StatefulBean passivation is broken (ClassCastException in org.jboss.ejb3.stateful.NestedStatefulBeanContext)
------------------------------------------------------------------------------------------------------------
Key: EJBTHREE-657
URL: http://jira.jboss.com/jira/browse/EJBTHREE-657
Project: EJB 3.0
Issue Type: Bug
Affects Versions: EJB 3.0 RC8 - FD
Reporter: Carlo de Wolf
Priority: Critical
StatefulBean passivation is broken, because there is a conflict between what gets serialized (attribute contains) and what gets unserialized (attribute beanMO).
11:41:37,109 ERROR [STDERR] Caused by: java.lang.ClassCastException: java.util.ArrayList
11:41:37,109 ERROR [STDERR] at org.jboss.ejb3.stateful.NestedStatefulBeanContext.readExternal(Neste
dStatefulBeanContext.java:60)
11:41:37,109 ERROR [STDERR] at org.jboss.serial.persister.ExternalizePersister.readData(Externalize
Persister.java:72)
11:41:37,109 ERROR [STDERR] at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectD
escriptionFromStreaming(ObjectDescriptorFactory.java:411)
11:41:37,109 ERROR [STDERR] at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromD
escription(ObjectDescriptorFactory.java:81)
11:41:37,109 ERROR [STDERR] at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectIn
put.readObject(DataContainer.java:639)
11:41:37,109 ERROR [STDERR] at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride
(ObjectInputStreamProxy.java:68)
11:41:37,109 ERROR [STDERR] at java.io.ObjectInputStream.readObject(ObjectInputStream.java:333)
11:41:37,109 ERROR [STDERR] at java.util.ArrayList.readObject(ArrayList.java:592)
11:41:37,109 ERROR [STDERR] ... 74 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
18 years, 11 months
[JBoss JIRA] Created: (JBMESSAGING-511) JDBC and Transaction close/cleanup operations should be bullet-proofed JDBCChannelMapper and elsewhere.
by Joel Lindheimer (JIRA)
JDBC and Transaction close/cleanup operations should be bullet-proofed JDBCChannelMapper and elsewhere.
-------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-511
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-511
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.0.1.CR4
Environment: Windows
Reporter: Joel Lindheimer
Assigned To: Ovidiu Feodorov
I am concerned with object close and wrap.end() methods in JDBCChannelMapper possibly being bypassed if an exception is thrown in the rs.close(), ps.close() blocks (code below is an example of what is currently in the JDBCChannelMapper).
JDBCChannelMapper :
public DurableSubscription getDurableSubscription(String clientID, String subscriptionName, MessageStore ms, PersistenceManager pm, MemoryManager mm) throws Exception {
// Look in memory first
DurableSubscription sub = getDurableSubscription(clientID, subscriptionName);
if (sub != null) {
return sub;
}
//Now look in the db
Connection conn = null;
PreparedStatement ps = null;
ResultSet rs = null;
TransactionWrapper wrap = new TransactionWrapper();
try {
conn = ds.getConnection();
ps = conn.prepareStatement(selectDurableSub);
(do stuff here... )
return sub;
} finally {
if (rs != null) { // JL what if it blose up here?
rs.close();
}
if (ps != null) { // JL or here?
ps.close();
}
if (conn != null) { // or here?
conn.close();
}
wrap.end();
}
}
--
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, 11 months
[JBoss JIRA] Created: (JBCACHE-832) Develop CacheSPI impl for use in JBoss JMX microkernel
by Brian Stansberry (JIRA)
Develop CacheSPI impl for use in JBoss JMX microkernel
------------------------------------------------------
Key: JBCACHE-832
URL: http://jira.jboss.com/jira/browse/JBCACHE-832
Project: JBoss Cache
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: 2.0.0.GA
If we want JBC 2.0 to work in AS 4.2, we'll need a way to construct a CacheSPI via the 4.x microkernel/SARDeployer.
Initial thoughts:
1) Create class "CacheSPIWrapper" that implements CacheSPI, plus exposes all the configuration-related mbean attributes from JBC 1.4. This is the class that's used for the "class" attribute of the mbean in the -service.xml file.
2) Class when instantiated also instantiates a Configuration object. When SARDeployer invokes the setters on the legacy mbean attributes, the values are passed through to the Configuration object.
3) In createService(), the Configuration object is passed to DefaultCacheFactory, which returns an instance of the standard CacheSPI impl. CacheSPIWrapper holds a ref to this object for use as a delegate.
4) CacheSPIWrapper implements CacheSPI by delegation to the standard object.
If we decide we don't want to support use of JBC 2.0 in 4.2, this task can be closed.
--
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, 11 months
[JBoss JIRA] Created: (JBAS-3985) EJB3 hot redeployment causes a permanently locked file handle
by Vladimir Ralev (JIRA)
EJB3 hot redeployment causes a permanently locked file handle
-------------------------------------------------------------
Key: JBAS-3985
URL: http://jira.jboss.com/jira/browse/JBAS-3985
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment services, EJB3
Affects Versions: JBossAS-4.0.5.GA
Environment: Windows XP Pro, JRE 1.5_9, JBoss AS 4.0.5.GA, EJB3.CR9.patch1
Reporter: Vladimir Ralev
Assigned To: Dimitris Andreadis
I am not sure which component is responsible for the bug, but since it happened with an ejb3-jar I am rising it here. If it doesn't belong here please forward it the right place.
1. I copy titan.jar to the deploy folder -> the server deploys the ejb3 application and says ejb running
2. I delete titan.jar from the deploy folder -> the server says that the app is undeployed
3. I copy titian.jar in the deploy folder again -> the server deploys the ejb3 application and says ejb running again
(everything seems ok for now, here comes the problem)
4. I try to delete titan.jar from the deploy folder -> I get a windows explorer error message saying that the file is in use and can't be deleted.
When I checked with process explorer which process is using the file it turned out it's the java.exe process (the server didn't release the handle?).
This doesn't not occur on Linux!
--
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, 11 months