JBossDeveloper

Did you add the async namespace in your components.xml?
Try to validate it with Eclipse.

Naresh,

My example:

|@In QuartzJMSHandler quartzJMSHandler;
...
Calendar cal = Calendar.getInstance();
                        cal.set(2010,12, 31); // Now
                        quartzMonitorHandler.checkMonitors(new Date(), 30000L, cal.getTime());
                        quartzJMSHandler.checkTopic(new Date(), 5000L, cal.getTime());
log.info("Timers initialized");..|

.

Which basically means: start now and repeat every 5 seconds. The last parameter (end data was more playing than really necessary...)

Using Quarts is more for is aditional features, but not really necessary, you could the Ejb-timer also.

Concerning you example: I wouldn't start the timer directly from inside the same bean you're using for polling purposes but that's a question of taste. However you're also using an event with another signature than the Observing method. You should add the  right number of parameters to pollQueue. Also put the bean in a specific scope its now in default scope and I think you need it in Application scope and autocreated. Also have the timer managed by Seam this helps in managing th timer from other beans (starting/stopping/changing tims etc.)

Hopefully this helps.

Leo

Sorry for the repeat, it gave me an error the first time, so I've uploaded a second time.

Leo

Just want to mention that a comparable discusssion is going on in:

http://seamframework.org/Community/SeamJMSActiveMQHibernate

Leo

I think you guys are making this much harder than it has to be. As you have probably figured out, JMS message listeners are not intercepted by Seam because they are instantiated directly by the EJB container. Therefore, you don't get injection. But that doesn't mean you can't get access to Seam components.

First, a little background. Seam backs the application scope with a static map. That means that at all times in the same classloader, Seam can access the set of components and any application-scoped instances. The only other interesting context is the event context, which only needs to be created for the request (in this case a message announcement) so that you can use event-scoped components. (As a bonus, Seam can also rev up the business process scope at will, since it's also a non-HTTP scope).

Great, so how do you make the scopes active for the duration of the message announcement (i.e. the invocation of onMessage)? Well, peeking at the code used by the asynchronous dispatcher infrastructure, we see the following:

Lifecycle.beginCall();
// message handling goes here
Lifecycle.endCall();

Between the Lifecycle methods, you can ask Seam for any component by name.

MessageProcessor processor = (MessageProcessor) Component.getInstance("messageProcessor");

or by class, which resolves the name from the @Name annotation and looks up by name:

MessageProcessor processor = (MessageProcessor) Component.getInstance(MessageProcessor.class);

The only downside is that you can't use injection. But you can use injection within the component you are looking up, so this is sort of like the service-locator or JNDI lookup pattern.

Here's a complete example:

@Name("messagePublisher")
public class MessagePublisher {
     @In QueueSender testQueueSender;

     @In QueueSession queueSession;

     private String message;

     public void publish() throws JMSException {
          if (message != null && message.length() > 0) {
               System.out.println("Publishing message: " + message);
               testQueueSender.send(queueSession.createTextMessage(message));
          }
     }

     public void setMessage(String message) {
          this.message = message;
     }

     public String getMessage() {
          return message;
     }

}

@MessageDriven(activationConfig = {
     @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
     @ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/testQueue")
})
public class MessageReceiver implements MessageListener {

     @Override
     public void onMessage(Message message) {
          try {
               Lifecycle.beginCall();
               MessageProcessor processor = (MessageProcessor) Component.getInstance("messageProcessor");
               processor.process(((TextMessage) message).getText());
          } catch (JMSException e) {
               e.printStackTrace();
          }
          finally {
               Lifecycle.endCall();
          }
     }

}

@Name("messageProcessor")
public class MessageProcessor {
     public void process(String message)
     {
          System.out.println("Received message: " + message);
     }
}

To use Seam components, keep in mind that the listener cannot be a remote client. That's because it would be outside of Seam. Of course, if the remote client is another Seam application, then you can use Seam components from that application. But Seam isn't going to be able to see across the wire.

It would be great if we could either provide an EJB interceptor to handle the Seam setup or a ContextualMessageHandlerRequest.

public abstract class ContextualMessageHandlerRequest<T> {

     private Message message;
     private boolean setupRequired = false;
     private T delegate;

     public ContextualMessageHandlerRequest(Message message) {
          this.message = message;
          this.setupRequired = !Contexts.isApplicationContextActive() && !Contexts.isEventContextActive();
     }

     public void run() {
          setup();
          try {
               process();
          } finally {
               cleanup();
          }
     }
     public abstract void process();

     public T getDelegate() {
          return delegate;
     }
     
     @SuppressWarnings("unchecked")
     public Class<T> getDelegateClass() {
          return (Class<T>) ((ParameterizedType) getClass().getGenericSuperclass()).getActualTypeArguments()[0];
     }
     
     public Message getMessage() {
          return message;
     }
     
     // convenience method
     public TextMessage getTextMessage() {
          if (message instanceof TextMessage) {
               return ((TextMessage) message);
          }
          return null;
     }

     @SuppressWarnings("unchecked")
     private void setup() {
          if (setupRequired) {
               Lifecycle.beginCall();
          }

          Contexts.getEventContext().set(AbstractDispatcher.EXECUTING_ASYNCHRONOUS_CALL, true);
          Class<T> delegateClass = getDelegateClass();
          if (delegateClass != null) {
               delegate = (T) Component.getInstance(delegateClass);
          }
     }
     
     private void cleanup() {
          Contexts.getEventContext().remove(AbstractDispatcher.EXECUTING_ASYNCHRONOUS_CALL);
          if (setupRequired) {
               Lifecycle.endCall();
          }
     }
}

Then you can simplify the call (or at least make it more generic) in onMessage to the following:

new ContextualMessageHandlerRequest<MessageProcessor>(message) {

     @Override
     public void process() {
          try {
               getDelegate().process(getTextMessage().getText());
          } catch (JMSException e) {
               e.printStackTrace();
          }
     }
}.run();

Notice that the delegate is being looked up by type (which Seam uses to resolve a name) based on the generic type parameter. Not required, but certainly an interesting approach.

Perhaps a JIRA?

Dan,

many thanks for this great explanation !!! This is what we needed to know. Maybe not only a JIRA but also an addition to the examples or the Seam  documentation?

Leo

Jira created

https://jira.jboss.org/jira/browse/JBSEAM-4235