January 2007 - jboss-jira - Jboss List Archives

[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

3
2
0 / 0

[JBoss JIRA] Created: (JBFORUMS-163) Performance tests based on jboss.com nukes forums access logs

by Ryszard Kozmik (JIRA)

Performance tests based on jboss.com nukes forums access logs ------------------------------------------------------------- Key: JBFORUMS-163 URL: http://jira.jboss.com/jira/browse/JBFORUMS-163 Project: JBoss Forums Issue Type: Task Components: Forum Test Suite Reporter: Ryszard Kozmik Assigned To: Ryszard Kozmik Priority: Blocker Fix For: 1.1.0 Alpha We need to make sure that JBoss Forums are enough performant before trying to deploy moving all load from jboss.com nukes forums to them. IT should be able to provide nukes forums access logs and basing on them we should be able to create much more realistic load tests. junitperf toolkit with JProfiler might be a good choice for this task. -- 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

2
1
0 / 0

[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

4
6
0 / 0

[JBoss JIRA] Created: (JBAOP-351) Intercept Integer and Long bit manipulation methods

by Elias Ross (JIRA)

Intercept Integer and Long bit manipulation methods --------------------------------------------------- Key: JBAOP-351 URL: http://jira.jboss.com/jira/browse/JBAOP-351 Project: JBoss AOP Issue Type: Task Security Level: Public (Everyone can see) Reporter: Elias Ross Add support for Integer.bitCount(), etc. appearing in JDK 1.5 -- 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

3
7
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-609) Decide the way to go forward (with or without Remoting)

by Ovidiu Feodorov (JIRA)

Decide the way to go forward (with or without Remoting) ------------------------------------------------------- Key: JBMESSAGING-609 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-609 Project: JBoss Messaging Issue Type: Task Components: JMS Remoting Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Blocker Fix For: 1.2.0.Alpha2 Conclude the http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971228 discussion thread and make a decision on how to go further: 1. Modify Remoting to include Messaging-specific requirements (asynchronicity, AMQP, etc) 2. Implement our own remoting solution. -- 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

3
9
0 / 0

[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

2
7
0 / 0

[JBoss JIRA] Created: (JBAS-3949) Upgrade to log4j 1.2.14

by Dimitris Andreadis (JIRA)

Upgrade to log4j 1.2.14 ----------------------- Key: JBAS-3949 URL: http://jira.jboss.com/jira/browse/JBAS-3949 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Logging Reporter: Dimitris Andreadis Assigned To: Dimitris Andreadis Fix For: JBossAS-4.2.0.CR1 Upgrade to the latest stable log4j release 1.2.14 http://logging.apache.org/log4j/docs/download.html -- 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

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-928) Consider adding a method to expose lifecycle state

by Brian Stansberry (JIRA)

Consider adding a method to expose lifecycle state -------------------------------------------------- Key: JBCACHE-928 URL: http://jira.jboss.com/jira/browse/JBCACHE-928 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Manik Surtani Fix For: 2.0.0.BETA1 In 1.x, in the AS at least, the lifecycle state of a cache could be determined via the inherited ServiceMBeanSupport.getState(). Now there is no way to find out if the cache is created/started/stopped/destroyed. We should consider adding this, perhaps as a method in the Cache interface. -- 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

3
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-727) @Depends annotation does not work in EJB3 Embeddable release

by Magesh Kumar B (JIRA)

@Depends annotation does not work in EJB3 Embeddable release ------------------------------------------------------------ Key: EJBTHREE-727 URL: http://jira.jboss.com/jira/browse/EJBTHREE-727 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC9 - FD Reporter: Magesh Kumar B The ServiceOne, ServiceTwo and ServiceThree example given in the EJB3.0 documentation does not work when testing with the embeddable release -- 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

3
2
0 / 0

[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

3
4
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