I'm trying to run mockrunner in an appserver like JBoss. In my setup I want to bind a mock connection factory and a mock queue to JNDI. But I get
Caused by: java.io.NotSerializableException: com.mockrunner.mock.jms.MockQueueConnectionFactory
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
at java.rmi.MarshalledObject.<init>(MarshalledObject.java:92)
at org.jnp.interfaces.MarshalledValuePair.<init>(MarshalledValuePair.java:65)
at org.jnp.interfaces.NamingContext.createMarshalledValuePair(NamingContext.java:1384)
at org.jnp.interfaces.NamingContext.bind(NamingContext.java:627)
… 41 more
do you want me to contribute the "implements Serializable" changes needed in the mockrunner codebase ?
regards,
Tom Baeyens
Founder and lead of JBoss jBPM http://jbpm.org
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mockrunner JMS was never meant to run inside JBoss or any other appserver. It's just a simple test implementation used with a custom in-memory JNDI-context. Making the connection factories serializable means making everything in Mockrunner JMS serializable, including the controller classes like TransmissionManager and DestinationManager. I really don't know if this makes sense. However I'll do it, I think it won't hurt. There are some minor issues with interfaces which allow non-serializable custom implementations (and can be added to mock classes). So everything in JMS will claim to be serializable but really trying to serialize this stuff may fail (but should work in normal cases). I keep it for JMS for now not making serializable everything in Mockrunner. As mentioned, the classes do not have to be serializable when Mockrunner is used as a simple test framework outside any container (this is the purpose of Mockrunner)
Regards,
Alwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understand the original context of mockrunner. But our examples test suite runs on various environments: standalone, on tomcat, on jboss, on spring, with various dbs and transaction demarcations. We have hudson jobs to run it in all these environments.
So we want those tests to run inside and outside the appserver.
It turns out that the only difference is the JNDIUtil.initMockContextFactory(). That does not have to be called in the appserver environment. In theory, i think this will work nicely. The unit test will take care of publishing the queues and dealing with the messages. Downside is that you don't use the real JMS impl. But another advantage is that you don't have to mess with the app server setup to create the message queues and connection factories.
Do you think it would be bad for mockrunner to add the "implements Serializable" to the classes ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Adding the "implements Serializable" is not bad for Mockrunner :-) I already did it (it's in CVS). The only thing is that we have to be sure that everything is really serializable but as mentioned, everything should be fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm trying to run mockrunner in an appserver like JBoss. In my setup I want to bind a mock connection factory and a mock queue to JNDI. But I get
Caused by: java.io.NotSerializableException: com.mockrunner.mock.jms.MockQueueConnectionFactory
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
at java.rmi.MarshalledObject.<init>(MarshalledObject.java:92)
at org.jnp.interfaces.MarshalledValuePair.<init>(MarshalledValuePair.java:65)
at org.jnp.interfaces.NamingContext.createMarshalledValuePair(NamingContext.java:1384)
at org.jnp.interfaces.NamingContext.bind(NamingContext.java:627)
… 41 more
do you want me to contribute the "implements Serializable" changes needed in the mockrunner codebase ?
regards,
Tom Baeyens
Founder and lead of JBoss jBPM
http://jbpm.org
Hi Tom,
Mockrunner JMS was never meant to run inside JBoss or any other appserver. It's just a simple test implementation used with a custom in-memory JNDI-context. Making the connection factories serializable means making everything in Mockrunner JMS serializable, including the controller classes like TransmissionManager and DestinationManager. I really don't know if this makes sense. However I'll do it, I think it won't hurt. There are some minor issues with interfaces which allow non-serializable custom implementations (and can be added to mock classes). So everything in JMS will claim to be serializable but really trying to serialize this stuff may fail (but should work in normal cases). I keep it for JMS for now not making serializable everything in Mockrunner. As mentioned, the classes do not have to be serializable when Mockrunner is used as a simple test framework outside any container (this is the purpose of Mockrunner)
Regards,
Alwin
I understand the original context of mockrunner. But our examples test suite runs on various environments: standalone, on tomcat, on jboss, on spring, with various dbs and transaction demarcations. We have hudson jobs to run it in all these environments.
So we want those tests to run inside and outside the appserver.
It turns out that the only difference is the JNDIUtil.initMockContextFactory(). That does not have to be called in the appserver environment. In theory, i think this will work nicely. The unit test will take care of publishing the queues and dealing with the messages. Downside is that you don't use the real JMS impl. But another advantage is that you don't have to mess with the app server setup to create the message queues and connection factories.
Do you think it would be bad for mockrunner to add the "implements Serializable" to the classes ?
I understand.
Adding the "implements Serializable" is not bad for Mockrunner :-) I already did it (it's in CVS). The only thing is that we have to be sure that everything is really serializable but as mentioned, everything should be fine.