Well, I finally found what was causing this classcastexception;
I was using a standalone client to test my EJB's. When the standalone client looked up a sessionbean, it seems remote interface was kept alive. When I redeploy my application, JBoss doesn't replace the old interface with the new one. I don't know why this is, but I think it has something to do with the client stub and that the underlying connections stay alive.
Now I've put everything in an ear application and use a test servlet to test my EJB's instead of a standalone client.
I hope this may help if you're having the same ClasscastExceptions....
Bart
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3996306#3996306
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3996306
In working through the examples, I see that the concurrent-request-timeout appears to be extremely small -- at most, 50 seconds. So, for example, if you start up a couple of conversations, they will timeout very quickly.
My question is, is there a technical reason for this? Obviously, the longer you allow, the more likely you will run into optimistic locking conflicts, but are there any other issues?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3996302#3996302
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3996302
