I have been playing around with JMS 2 a bit. I don’t have that much experience with it earlier and found out session-to-session messaging to be pretty hard with Java EE. JSMContext isn’t allowed to have asynchronous listener. This is clearly something into which it isn’t designed for.
I wrote an experimental helper and a chat app that uses it that creates “application managed” jms context for each interested UI. This seems to work pretty well. I also wrote it so that it should in theory survive from session-failover, but that is yet to be proven. In case you have experience with JSM (2) and Vaadin, I’d be grateful for all comments and improvement ideas.
I came across your post as im trying to integrate JMS in a vaadin application. I followed the application sample you provided but it throws an exception:
|Severe: javax.jms.JMSRuntimeException: [C4306]
: This method may not be called in a Java EE web or EJB container
It breaks on the line
48 of
MainUI class when starting
MyMessageReceiver . I spent one day already but cant make JMS work with vaadin (on Glassfish 4.1)
IIRC, I tested the application only with Wildfly. It appears that Glassfish is more picky when it comes to adding listeners to JMSContext. In Wildfly it did the same if I just tried to inject JMSContext.
I think the correct solution would be to have a message driven bean instead (per JVM) and Vaadin UI’s should register themselves to that when then wan’t be be notified by a certain message.
But would it be possible to guarantee the creation of a single MessageDriven bean per VM? As far as i know these beans are handled by the EjbContainer without much to handle regarding their lifecycle. I tried a similar approach by having a static list of UI references as listeners on a MessageDriven bean but was not possible to call these UI’s methods as it throws an exception complaining of calling vaadin resources within the ejb/jms context. Anyway thanks for all your replies. It was really helpful. It seems like there is a miscompatability between Vaadin and Glassfish regarding JMS. Previously i tested sending JMS messages between different applications (EJB and JSF) on the same Glassfish instance successfully therefore i thought it should be a similar approach. However, if you run on any resource regarding this issue please post it on the forum. Id be highly interested to know if someone has figured out a workaround.
JSF and Vaadin are exactly on the same line here. With Vaadin you can in just same way consume JMS messages, using the synchronous API (receive(), receive(long timeout), receiveNoWait()). The issue, in some Java EE containers (read: glassfish), is just with the asynchronous API (adding listener to JMSConsumer). I tried this last fall as I wanted a very snappy chat client to demonstrate Vaadin Push, WebSocket and scalability. For normal business apps this is usually not an issue.
I looked into the code of the AbstractMessageHub and I do not understand for what the methods
registerActivationListener();
and
deregisterActivationListener();
are needed. Could you explain it to me maybe?
Also the code to refetch the ui seems somehow strange (I mean this line: )
if (getClass().isAssignableFrom(ui.getClass())) {
This condition will never be true (from my point of view) because getClass() will return the AbstractMessageHub Class (or the implementing Class) and this will not be assignable from a UI-Class, right?