6 Replies Latest reply on May 14, 2013 1:18 PM by ansur

    NotificationListener equivalent

    ansur Newbie

      We're in the middle of porting some MBeans from a JBoss 5 installation to direct EJB invocations on a JBoss 7.2.0 installation.

      Some of these invocations take quite a while. To keep the user notified of the progress, we were attaching a javax.management.NotificationListener to the MBeanServerConnection retrieved from JBoss.


      I was wondering whether on JBoss 7 there's a similar mechanism for EJB invocations. Afterall the xnio/remote connection already passes some information, up to even a stacktrace if something went wrong on the serverside.

      Is there a way to hook in into this mechanism?

        • 1. Re: NotificationListener equivalent
          Stephen Coy Master

          I think that something like this might work:



          public class PollableWorkerBean implements PollableWorker {


               private AtomicInteger progess;


               public void reset() {





               public Future<Result> performWork(String arg) {

                    while (progress.incrementAndGet() < 100) {

                         do some work;


                    return new AsyncResult<Result>(new Result(results));



               public int getProgess() {

                    return progress.get();









               PollableWorker worker = ...


               Future<Result> futureResult = worker.performWork("some arg");

               while (!futureResult.isDone() && !futureResult.isCancelled()) {

                    int progress = worker.getProgress();

                    report progress





          There's a chance that this may run afoul of the method call serialisation requirements on stateful session beans. I couldn't find anything in the spec regarding this and asynchronous method invocation.

          • 2. Re: NotificationListener equivalent
            ansur Newbie

            I forgot to mention a rather important piece of information: it's a remote EJB invocation. So client/server communication. Indeed what you suggest would work, but it's not a problem that the actual execution goes slowly, it's that we need to keep the client updated.


            The actual work being done is installing/updating modules on the AS. So the whole process is downloading new EAR files, performing backups, undeploying, deploying, some DB configuration etc. We're sending back textual information to the client so he knows what the process is currently doing. This was working well with the NotificationListener/MBeanServerConnection combination, now I'm wondering whether we can send back this information when doing a remote EJB call using EJBClientConfiguration/Context lookup.

            • 3. Re: NotificationListener equivalent
              Stephen Coy Master

              The above (if it works at all) should work in a remote situation.


              But a lot of what you're doing can be done programmatically using the management API, although there won't be any progress feedback. You should investigate this if you want to future proof yourself.

              • 4. Re: NotificationListener equivalent
                ansur Newbie

                Everything is done through the management API. That's not the problem. It's just the feedback I need to build in still between the steps.

                • 5. Re: NotificationListener equivalent
                  Elias Ross Master

                  Something that comes to mind is using JMS. Create a temporary queue on the client. Have the EJB send messages (non-transacted) to this temporary queue.


                  Here's some more info: http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html


                  For JavaScript (web apps) you can use Ajax.

                  • 6. Re: NotificationListener equivalent
                    ansur Newbie

                    In the end I used quite a similar solution as we had before, but just a bit adapted to JBoss 7: extend from NotificationBroadcasterSupport, make it a @Singleton and use the @PostConstruct and @PreDestroy functionality to register the instance as an MBean.