Events from ContextualHttpServletRequest

[nickarls]

Is the ContextualHttpServletRequest sandboxed in some or why can't I succeed in raising events from there?

I have an observer that works fine inside the application but when I raise the same event from an external servlet wrapped in a ContextualHttpServletRequest, I get no reaction.

The events are global (singelton), aren't they? Or am I missing something fundamental?

[pmuir]

Should work, post your code.

Can you debug through the Seam source to see what is going on?

[nickarls]

     protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

          new ContextualHttpServletRequest(request) {

               public void process() throws Exception {

                    String msg = ServletContexts.getInstance().getRequest().getParameter("msg");

                    Events.instance().raiseEvent("incoming_message", msg);

               }

               

          }.run();

     }

I'm trying to send messages through the servlet. The listener is an ICEFaces onDemandRenderer that pushes popups to the clients

I'll try hooking up the source if you can't see any obvious errors...

[nickarls]

No, wait. There is something fishy here. If they would be global then apps that use events for execution flow would get all messed up. But e.g. seam postInitialize is global? Confused...

[nickarls]

Aah. OK. If the observer is in application scope it works fine.

Now the problem remains of distributing the event to the clients.

Are there any constructs for this or do I just have to do an own observer pattern for the clients against the application scoped component?

[nickarls]

But if I make a

public interface MessageListener {

     public void message(String message);

}

and add a data structure and subscribe/unsubscribe functionality to the application scoped event listener I get NPE:s in my beans when doing

  for (MessageListener listener : listeners) {

    listener.message(message);

  }

since there is no injection available (the beans are not the same as when registering).

Any clues as how to do this kind of messaging?

[pmuir]

The event is called within the context of the raising action (so event, then conversation etc.) - so I would think if the servlet is participating in the session and conversation it should be able to observe there as well. If not, I think it is probably a bug.

[nickarls]

The servlet is called from outside the application so I don't think it is participating in anything.

I can live with the event being observed with the application scoped component. Now the problem (mentioned in the post above) is the observer pattern not working since the seam managed beans that I register are half the bean they used to be when called again (no injected stuff)

[nickarls]

The problem is apparently that since the event originates from the application scope, the beans don't get their original state restored that they had in their own conversations when they were injected.

If I pass along their conversation ID:s when registering the listeners, is it possible to simulate their conversation, sort of

for (MessageListener listener : listeners) {

  Conversation.instance().setId(listenerConversationId)

  listener.message(message);

}

[nickarls]

Apparently ConversationEntries.getInstance().getConversationEntry(assumeIdentity).select(); doen't do the trick, either...

[nickarls]

An no luck on Manager.instance().setCurrentConversationId(...) either...

[pmuir]

Try

Manager.instance().switchConversation(id);

[nickarls]

Ngh. No go. Not allowed across session for security reasons, I guess?

[pmuir]

Yes, conversations are stored in the session, so you must be in the same session.

There is an open JIRA for making the context stores pluggable, but this isn't implemented currently.

[nickarls]

I would love to have some sort of Events.getInstace().raiseGlobalEvent(user_logged_on). Would it overlap with the existing JIRA?

What would be the remaining options? JMS? I'm on WAR so it pretty much rules out MDBs. A thread polling the application scoped component?