[JCA/JBoss] - Classloading issue either with JMS inflow, TM, or Hibernate
by genman
Issue with JBoss 4.2.0
Hibernate can't seem to find my class when it does a commit from a MDB. It seems Hibernate doesn't know the classloader, and
The way to reproduce this is to create an EJB3 entity with a Serializable field, modify that field in an MDB, and you get this:
| 2007-07-25 11:14:41,313 ERROR [AbstractFlushingEventListener] Could not synchronize database state with session
| org.hibernate.type.SerializationException: could not deserialize
| at org.hibernate.util.SerializationHelper.deserialize(SerializationHelper.java:214)
| at org.hibernate.util.SerializationHelper.deserialize(SerializationHelper.java:240)
| at org.hibernate.type.SerializableType.fromBytes(SerializableType.java:82)
| at org.hibernate.type.SerializableType.deepCopyNotNull(SerializableType.java:74)
| at org.hibernate.type.MutableType.deepCopy(MutableType.java:25)
| at org.hibernate.type.SerializableToBlobType.deepCopy(SerializableToBlobType.java:102)
| at org.hibernate.type.TypeFactory.deepCopy(TypeFactory.java:353)
| at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:114)
| at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:248)
| at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:232)
| at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:140)
| at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
| at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
| at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
| at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
| at org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:515)
| at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:114)
| at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:249)
| at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:88)
| at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
| at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1256)
| at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:135)
| at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:87)
| at org.jboss.resource.adapter.jms.inflow.JmsServerSession$XATransactionDemarcationStrategy.end(JmsServerSession.java:494)
| at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:248)
| at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204)
| at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275)
| at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: java.lang.ClassNotFoundException: No ClassLoaders found for: com.example.msg.Message
| at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:306)
| at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:514)
| at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:408)
| at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
| at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
| at java.lang.Class.forName0(Native Method)
| at java.lang.Class.forName(Class.java:242)
| at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:574)
| at org.hibernate.util.SerializationHelper$CustomObjectInputStream.resolveClass(SerializationHelper.java:268)
| at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1538)
| at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460)
| at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693)
| at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
| at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
| at org.hibernate.util.SerializationHelper.deserialize(SerializationHelper.java:210)
| ... 28 more
|
Looks like serialization expects the context classloader to be set correctly for the calling thread:
|
| public final class SerializationHelper {
| ...
| /**
| * Custom ObjectInputStream implementation to more appropriately handle classloading
| * within app servers (mainly jboss - hence this class inspired by jboss's class of
| * the same purpose).
| */
| private static final class CustomObjectInputStream extends ObjectInputStream {
| ClassLoader loader = Thread.currentThread().getContextClassLoader();
|
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068010#4068010
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068010
18Â years, 9Â months
[EJB 3.0] - Callbacks with in Message Driven Pojo?
by boilerk19
I like the idea of the MDP for simplifying the code for async calls, but in the examples that I see, there is no way for the client to know when the call has completed -- other than polling for some resultant type of data.
Has there been any thought to being to pass some sort of callback object that the consumer can invoke, (callback probably tied to some temporary queue that the client who issued the original async call is listening on)?
In the examples, it is mentioned regarding using the @CurrentMessage to get access to the JMS message including the ReplyTo field, yet I don't see any mechanism of how the sender can set the replyTo so that they can setup their own callback listener on that field.
Additionally, considering that internally an ObjectMessage is being created/sent, does it even specify a replyTo arg?
thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068009#4068009
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068009
18Â years, 9Â months
[JBoss Messaging] - Re: Problem after mcving from 1.3 to 1.4
by HibsMax
When I run my test I get lots of these messages on the stdout:
2007-07-26 15:14:35,820 WARN [org.jboss.messaging.core.impl.JDBCPersistenceManager] SQLException caught - assuming deadlock detected, try:1
java.sql.SQLException: ORA-02291: integrity constraint (MANDERSO.SYS_C0011668) violated - parent key not found
I hacked the DB and removed the referential integrity constraint (JBM_MSG_REF.MESSAGE_ID -> JBM_MSG.MESSAGE_ID) just to see what would happen i.e. not considering it a legitimate fix, and I ceased getting the messages and the test ran. I started getting other stack traces instead.
I know that the database schema changed between 1.3 and 1.4. Is there some other configuration required to avoid the SQLException above? When I googled I only found one issue and that was re: duplicate keys, not parent key not found.
Thanks, Anders
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068003#4068003
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068003
18Â years, 9Â months