0 Replies Latest reply on Nov 24, 2011 5:47 AM by daniell

    Custom Statistics-Service for JBoss AS 5

    daniell

      Hi!

       

      We've a Java-Application using many SFSB and SLSB running on JBoss AS 5.1.0. There is a Webclient using Seam (but IMHO this shouldn't affect anything) and some native clients using the EJB3-facilities to use the application. Of course, webapp-users and remote-users have to login.

       

      So the user uses some services of our application (usually a method of a SFSB). This SFSB may use other resources to come to a result.

       

      Now, I've the following requirement: I want to write some statistic-data concerning the usage of "functionality" at predefined locations in the application. Typically, I would write this information when using the methods of our SFSBs. But we should be able to correlate calls to other SFSB.

      Example:

      User calls SFSB1, SFSB1 calls SFSB2, which uses some method of SFSB3.

      The result should look like

      SFSB1.doThis() called by user mike on 2011-03-03 11:25

        SFSB2.doThat() called by user mike on 2011-03-03 11:26

          SFSB3.help() called by user mike on 2011-03-03 11:27

          SFSB3 called by user mike ended execution on 2011-03-03 11:29

        SFSB2 called by user mike ended execution on 2011-03-03 11:30

      SFSB1 called by user mike ended execution on 2011-03-03 11:35

       

      (Somehow this looks like a transaction)

       

      One possibility is to pass some generated tag (or maybe a statistic object) with every method-call from SFSB to SFSB to be able to associate the calls to a single "thread". But of course, this is not what I want, since I have to change all interfaces.

      It would be fine to have some "magic" going on here: Annotate the methods which should be tracked or register an interceptor - and that's it (like the propagation of the PC).

       

      I already tried to use an interceptor and write some generated tag (or something else) into the InvocationContext (the contextData). But the context is not propagated from one call to another (which sounds reasonable).

       

      So my main problem (up to now ) is, that I don't know where to store the information to share among the interceptors of the different methods.

      Or maybe I'm completely on a dead end and there are better and more elegant ways to archive this...

       

      Thanks!