You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by "Allen, Robert R" <Ro...@ca.com> on 2013/10/28 16:54:42 UTC
TomEE+ActiveMQ 1.5.2: container classloader used for message
deserialization conflicts with LazyStopWebappClassLoader
Although it appears this topic has been discussed in other threads, I don't see guidance on the fix.
My tomee.xml contains the following boilerplate:
<tomee>
<!-- see http://tomee.apache.org/containers-and-resources.html -->
<Resource id="MyJmsResourceAdapter" type="ActiveMQResourceAdapter">
BrokerXmlConfig = broker:(tcp://localhost:61616)
ServerUrl = tcp://localhost:61616
</Resource>
<Resource id="MyJmsConnectionFactory" type="javax.jms.ConnectionFactory">
ResourceAdapter = MyJmsResourceAdapter
</Resource>
<Container id="MyJmsMdbContainer" ctype="MESSAGE">
ResourceAdapter = MyJmsResourceAdapter
</Container>
</tomee>
My webapp is initialized with container resources as follows. This results in a ConnectionFactory with the standard class loader, not the webapp loader, although the thread running the init() call has the webapp
LazyStopWebappClassLoader.
public class InitServlet extends HttpServlet {
@Resource
private ConnectionFactory connectionFactory;
public void init(ServletConfig config) throws ServletException
{
// ------- JMS service start --------------
try {
connection = connectionFactory.createConnection();
connection.start();
// set up cfgMgmt services
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MySvc mySvc = new MySvc (session);
}
public class MySvc implements MessageListener
{
private Session session;
private MessageConsumer consumer;
private MessageProducer writer;
public MySvc(Session session)
{
this.session = session;
writer = session.createProducer(null);
Destination destination_in =
session.createQueue("myqueue");
consumer = session.createConsumer(destination_in);
consumer.setMessageListener(this);
}
...
Because MySvc was created by the LazyStopWebappClassLoader thread, it's objects are loaded by it.
However when I receive a message:
public void onMessage(Message request)
{
Object reqObj = ((ObjectMessage) request).getObject();
if (!(reqObj instanceof BaseMsg)) {
throw new Exception("FUNCTIONALITY_NOT_SUPPORTED");
}
...
}
the deserialization was done by the connectionFactory's classLoader (not the webapp loader), so the class instanceof compare fails.
Is there a common sense way to resolve this in the TomEE environment configuration?
--------------------------------------------------------------------------
"The most precious thing we have is life, yet it has absolutely no
trade-in value."
Robert R. Allen Sr Principal Software Architect
robert.allen@ca.com (919)677-2899 CA Technologies
------------------------------
Re: TomEE+ActiveMQ 1.5.2: container classloader used for message
deserialization conflicts with LazyStopWebappClassLoader
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Yes
If you reproduce it on trunk that something we missed but I think it is
what we fixed in 1.6.0-snapshot
Le 29 oct. 2013 23:33, "robert.allen" <ro...@ca.com> a écrit :
> Hi Romain:
> By "fixed on trunk" do you mean that I should try to replicate the issue
> using the current 1.6-SNAPSHOT?
>
> My workaround for 1.5.2 is to simply not use the convenience @Resource
> annotation before ConnectionFactory and instead construct it inline, as in
>
> connectionFactory = new ActiveMQConnectionFactory(brokerURL);
>
> and in that case I think I dispose of need for tomee.xml in the
> TOMCAT_HOME/conf folder as well.
>
> Thanks,
> -Robert
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/TomEE-ActiveMQ-1-5-2-container-classloader-used-for-message-deserialization-conflicts-with-LazyStopWr-tp4665757p4665796.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
Re: TomEE+ActiveMQ 1.5.2: container classloader used for message
deserialization conflicts with LazyStopWebappClassLoader
Posted by "robert.allen" <ro...@ca.com>.
Hi Romain:
By "fixed on trunk" do you mean that I should try to replicate the issue
using the current 1.6-SNAPSHOT?
My workaround for 1.5.2 is to simply not use the convenience @Resource
annotation before ConnectionFactory and instead construct it inline, as in
connectionFactory = new ActiveMQConnectionFactory(brokerURL);
and in that case I think I dispose of need for tomee.xml in the
TOMCAT_HOME/conf folder as well.
Thanks,
-Robert
--
View this message in context: http://openejb.979440.n4.nabble.com/TomEE-ActiveMQ-1-5-2-container-classloader-used-for-message-deserialization-conflicts-with-LazyStopWr-tp4665757p4665796.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: TomEE+ActiveMQ 1.5.2: container classloader used for message
deserialization conflicts with LazyStopWebappClassLoader
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
would need to check with a sample but I think it was fixed on trunk
but not sure there was an "app" workaround.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2013/10/28 Allen, Robert R <Ro...@ca.com>:
> Although it appears this topic has been discussed in other threads, I don't see guidance on the fix.
>
> My tomee.xml contains the following boilerplate:
> <tomee>
> <!-- see http://tomee.apache.org/containers-and-resources.html -->
>
> <Resource id="MyJmsResourceAdapter" type="ActiveMQResourceAdapter">
> BrokerXmlConfig = broker:(tcp://localhost:61616)
> ServerUrl = tcp://localhost:61616
> </Resource>
>
> <Resource id="MyJmsConnectionFactory" type="javax.jms.ConnectionFactory">
> ResourceAdapter = MyJmsResourceAdapter
> </Resource>
>
> <Container id="MyJmsMdbContainer" ctype="MESSAGE">
> ResourceAdapter = MyJmsResourceAdapter
> </Container>
>
> </tomee>
>
>
> My webapp is initialized with container resources as follows. This results in a ConnectionFactory with the standard class loader, not the webapp loader, although the thread running the init() call has the webapp
> LazyStopWebappClassLoader.
>
> public class InitServlet extends HttpServlet {
>
> @Resource
> private ConnectionFactory connectionFactory;
>
> public void init(ServletConfig config) throws ServletException
> {
>
> // ------- JMS service start --------------
> try {
> connection = connectionFactory.createConnection();
> connection.start();
>
> // set up cfgMgmt services
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> MySvc mySvc = new MySvc (session);
> }
>
> public class MySvc implements MessageListener
> {
> private Session session;
> private MessageConsumer consumer;
> private MessageProducer writer;
>
> public MySvc(Session session)
> {
> this.session = session;
> writer = session.createProducer(null);
> Destination destination_in =
> session.createQueue("myqueue");
> consumer = session.createConsumer(destination_in);
> consumer.setMessageListener(this);
> }
>
> ...
>
> Because MySvc was created by the LazyStopWebappClassLoader thread, it's objects are loaded by it.
> However when I receive a message:
>
> public void onMessage(Message request)
> {
> Object reqObj = ((ObjectMessage) request).getObject();
> if (!(reqObj instanceof BaseMsg)) {
> throw new Exception("FUNCTIONALITY_NOT_SUPPORTED");
> }
>
> ...
> }
> the deserialization was done by the connectionFactory's classLoader (not the webapp loader), so the class instanceof compare fails.
>
> Is there a common sense way to resolve this in the TomEE environment configuration?
>
>
> --------------------------------------------------------------------------
> "The most precious thing we have is life, yet it has absolutely no
> trade-in value."
>
> Robert R. Allen Sr Principal Software Architect
> robert.allen@ca.com (919)677-2899 CA Technologies
> ------------------------------