4 Replies Latest reply on May 13, 2008 2:34 PM by tharter

    @Interceptors not working

    tharter

      I've just been beating this problem to death for about 3 days now. Maybe a year or so back I wrote some custom EJB3 interceptors. All was well. Now I find for no reason I can discern that they simply do not get invoked anymore.

      Specifically there is nothing super complex going on. I have an interceptor class, annotated method @AroundInvoke and a bean method in my deployment unit marked with @Interceptors(MyInterceptor.class). This has worked for quite some time. Lately, due to some reliability problems, I switched from jrocket R26.4 to R27.4. It appears that JBoss still DEPLOYS the interceptors


      2008-05-12 18:44:32,431 DEBUG [org.jboss.ejb3.EJBContainer] Method interceptors for public com.tradedesksoftware.etsdata.users.group.Company com.tradedesksoftware.etsdata.DataManagerBean.getCompany(int): [InterceptorInfo{class=class com.tradedesksoftware.interceptors.AuthReturnInterceptor, aroundInvoke=Intercept}]


      However when the business method is invoked, no interceptor. Same things seems to happen in unit tests using Embeddable EJB3, where the same interceptors also seemed to work fine previously. Even if I just add a 'do-nothing' interceptor that just spits out a log message, still not called.


      Anyone have even a clue what I can do to try to figure this out? I'm at a loss here. Cannot go back to R26.4 of jrockit and can't live without the interceptors either :(

        • 1. Re: @Interceptors not working
          jaikiran

          Which version of JBoss do you use? Please post the code of the EJB where the interceptor is used and also the interceptor class.

          • 2. Re: @Interceptors not working
            tharter

            Ah, OK. Sure enough, don't use jrockit R27.4. It is Java 1.6 compliant, bad news. EJB3 @Interceptors will just silently fail to be invoked... Feh. Also seems to create some subtle problems with JBoss WS 2.0.2.

            If anyone over there in the JBoss dev team happens to notice, being able to run 4.2.2 under a 1.6 compliant JRE is pretty significant. I don't care about 1.6 language features, they're trivial, but there are some HUGE performance and stability improvements in the latest JREs. Being stuck on jrockit R26.x is really not good news, and waiting however much longer it will be before 5.0 is stable and we can port our code base over is not great either.

            • 3. Re: @Interceptors not working
              tharter

              Oh, and I know this is slightly off the original topic, but I don't seem to see @Interceptors annotations honored at all in Embeddable. It seems like there can be 2 behaviors there. Either the interceptors just don't execute, or in some cases (and I haven't found exactly what the difference is) the EJB3 deployment unit itself simply never gets any of its interfaces mapped into JNDI.

              I didn't see anywhere this kind of thing was a 'known issue', but if anyone knows of a way to get that to work it would really simplify some of our unit testing workflow.

              • 4. Re: @Interceptors not working
                tharter

                Heh, still my day to be wrong about things.

                You can run JBoss 4.2.2.GA ok under jrockit R27.x. What you can't do is instrument an EJB3 SLSB using Cobertura, lol. It looks like instrumenting code causes @Interceptors annotation based interceptors (and possibly other things) to stop functioning.

                So, let that be a lesson to anyone who tries it. Be prepared for problems...

                Just to document this, what I've determined is:

                In both Embeddable EJB3 and both JBossAS 4.0.5.GA and 4.2.2.GA running under either jrockit R26.x (java 1.5) or R27.x (java 1.6) instrumenting code with Cobertura (at least with v1.8) causes EJB3 interceptors to fail to be called. JBoss apparently still recognizes the proper annotations, but the user interceptors are bypassed. While other things like transactions and generally any other container functionality I happened to rely on seemed to work I would be highly skeptical that the instrumented code behaves consistently with production code.

                Anyone used other test coverage instrumentation techniques successfully in container?