[JBoss JIRA] Created: (JBSER-115) Exception while deserialization of java.math.BigInteger in Sun JRE 1.6.0_14 if serialized using a previous version e.g. JRE 1.6.0_13.
by Mattias Neuling (JIRA)
Exception while deserialization of java.math.BigInteger in Sun JRE 1.6.0_14 if serialized using a previous version e.g. JRE 1.6.0_13.
--------------------------------------------------------------------------------------------------------------------------------------
Key: JBSER-115
URL: https://jira.jboss.org/jira/browse/JBSER-115
Project: JBoss Serialization
Issue Type: Bug
Affects Versions: 1.0.3 GA
Environment: Deserializing client:
- OS: Windows XP SP3 (32Bit)
- JRE 1.6.0_14
Serializing Server:
- OS: Linux Suse Enterprise (64 Bit)
- JDK 1.6.0_13 (64 Bit)
Reporter: Mattias Neuling
Assignee: Clebert Suconic
Failure while deserilizing java.math.BigInteger in java.math.BigDecimal on client side:
Stacktrace:
java.io.IOException: Current classpath has lesser fields on java.math.BigInteger than its original version
at org.jboss.serial.classmetamodel.StreamingClass.readStream(StreamingClass.java:98)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:381)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:82)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:643)
at org.jboss.serial.persister.RegularObjectPersister.readSlotWithFields(RegularObjectPersister.java:353)
at org.jboss.serial.persister.ObjectInputStreamProxy.defaultReadObject(ObjectInputStreamProxy.java:78)
at java.math.BigDecimal.readObject(Unknown Source)
... 42 more
In JDK 1.6.0_14 java.math.BigInteger has one field more than in previous versions. Serialization without JBoss Serialization is no problem since it implements the methods #readObject() and #writeObject().
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 1 month
[JBoss JIRA] Created: (EJBTHREE-1558) @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) ignored on MDB onMessage
by Justin Bertram (JIRA)
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) ignored on MDB onMessage
--------------------------------------------------------------------------------------
Key: EJBTHREE-1558
URL: https://jira.jboss.org/jira/browse/EJBTHREE-1558
Project: EJB 3.0
Issue Type: Bug
Affects Versions: AS 4.2.2.GA
Reporter: Justin Bertram
Even when putting:
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
on the onMessage method of an MDB a transaction is still started. This can be verified by using a simple MDB that sleeps for longer than the transaction timeout (300 seconds by default). For example:
import javax.ejb.ActivationConfigProperty;
import javax.ejb.MessageDriven;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.jms.Message;
import javax.jms.MessageListener;
import org.apache.log4j.Logger;
@MessageDriven(activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/A"),
@ActivationConfigProperty(propertyName = "maxSession", propertyValue = "3") })
public class ExampleEJB3MDB implements MessageListener {
private static final Logger logger = Logger.getLogger(ExampleEJB3MDB.class);
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public void onMessage(Message m) {
logger.info("message received, waiting for 10 mins...");
try {
Thread.sleep(600000); // 10 mins
} catch (InterruptedException e) {
}
logger.info("finished waiting");
}
}
When a message is sent to "queue/A" and the MDB picks it up it prints "message received, waiting for 10 mins..." in the log. After 5 minutes (300 seconds) the message appears in the log again because the transaction has timed-out and the message has been redelivered.
I believe the problem lies in org.jboss.ejb3.mdb.inflow.JBossMessageEndpointFactory in the isDeliveryTransacted method. Here is that method [1]:
public boolean isDeliveryTransacted(Method method) throws NoSuchMethodException
{
TransactionManagementType mtype = TxUtil.getTransactionManagementType(container);
if (mtype == javax.ejb.TransactionManagementType.BEAN) return false;
TransactionAttribute attr = (TransactionAttribute)container.resolveAnnotation(method, TransactionAttribute.class);
if (attr == null)
{
attr =(TransactionAttribute)container.resolveAnnotation(TransactionAttribute.class);
}
TransactionAttributeType type = TransactionAttributeType.REQUIRED;
if (attr != null) type = attr.value();
return type == javax.ejb.TransactionAttributeType.REQUIRED;
}
It seems there should be an explicit check for TransactionAttributeType.NOT_SUPPORTED. If the MDB uses @TransactionManagement(TransactionManagementType.BEAN) then the redelivery doesn't occur (since the code explicitly checks this attribute and returns false if it is present).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 1 month