Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1
    • Fix Version/s: 3.1_ms07
    • Component/s: cdi
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      14,831

      Description

      This issue is filed subsequent to the discussion in issue 13513 . It seems CDI
      interceptor bindings are not working for EJBs. I have simplified the test case
      from issue 13513 to remove OSGi from the picture and converted it to a simple
      web application with a Servlet calling a local EJB which has some interceptors
      as shown below;

      @WebServlet(urlPatterns="/*")
      public class MyServlet extends HttpServlet {
      @EJB UserService svc;

      public void service(ServletRequest req, ServletResponse res)

      { svc.findById(0); // call the ejb }

      }

      @Stateless
      @Secure // interceptor binding
      @Local
      public class UserServiceImpl implements UserService {

      public User findById(long userId) throws EJBException {
      ...
      LOG.log(Level.INFO, "Returning user

      {0}", u);
      }
      }

      @Inherited
      @Target({ TYPE, METHOD })
      @Retention(RUNTIME)
      @InterceptorBinding
      public @interface Secure
      {}

      @Secure
      @Interceptor
      public class SecurityInterceptor implements Serializable
      {
      @AroundInvoke
      protected Object invoke(final InvocationContext ctx) throws Exception
      {
      ...
      LOG.log(Level.INFO, "EJB Method called [Full]:\"{0}

      \" by Principal:

      {1}",
      new Object[]{getFullEJBClassName(interfaceMethod), p.toString()});
      LOG.log(Level.INFO, "EJB Method called [Methodonly]:{0} by
      Principal:{1}

      ", new Object[]

      {interfaceMethod.getName(), p.toString()}

      );

      return ctx.proceed();
      }
      }

      If unzip the attached interceptor-ejb-cdi-test.zip, it creates
      interceptor-ejb-cdi-test directory. Try the following:
      cd interceptor-ejb-cdi-test
      ./run.sh (this will compile, deploy and run the servlet)
      See the server.log, you shall not find any message from the interceptor.

      Now, open
      ./WEB-INF/classes/org/glassfish/cditest/user/impl/UserServiceImpl.java,
      uncomment the following line:
      @javax.interceptor.Interceptors(org.glassfish.cditest.security.interceptor.SecurityInterceptor.class)

      and run ./run.sh again. This time in server.log, you shall see interceptor
      message. As per the javadocs[1]:
      "If the target class is a CDI bean, by annotating both the interceptor class and
      the target class with an interceptor binding. "

      and as per CDI javadoc [2]:

      "Interceptors may be bound to any managed bean that is not itself an
      interceptor or decorator or to any EJB session or message-driven bean. An
      interceptor that is annotated @Interceptor may be identified by its interceptor
      bindings."

      [1]
      http://download.oracle.com/javaee/6/api/javax/interceptor/package-summary.html#package_description
      [2]
      http://download.oracle.com/javaee/6/api/javax/enterprise/inject/package-summary.html

      1. GLASSFISH-14831.diff
        0.7 kB
        Sivakumar Thyagarajan

        Activity

        Hide
        Sanjeeb Sahoo added a comment -

        Created an attachment (id=5555)
        Test case. Unzip, cd interceptor-ejb-cdi-test; ./run.sh

        Show
        Sanjeeb Sahoo added a comment - Created an attachment (id=5555) Test case. Unzip, cd interceptor-ejb-cdi-test; ./run.sh
        Hide
        chaoslayer added a comment -

        Thanks for this bug.

        Is there a chance that this can be fixed for MS7?

        Show
        chaoslayer added a comment - Thanks for this bug. Is there a chance that this can be fixed for MS7?
        Hide
        Sivakumar Thyagarajan added a comment -

        Thanks for the usecase. I have added devtests corresponding to these to track regressions at:
        interceptors/interceptors-use-of-interceptors-in-ejbs-through-at-interceptors
        interceptors/interceptors-use-of-interceptors-in-ejbs-through-interceptor-bindings

        Resolved as commit 43464. The EJBServices implementation of GlassFish was not handling duplicate Interceptor registrations.

        svn log -v -r 43464

        Show
        Sivakumar Thyagarajan added a comment - Thanks for the usecase. I have added devtests corresponding to these to track regressions at: interceptors/interceptors-use-of-interceptors-in-ejbs-through-at-interceptors interceptors/interceptors-use-of-interceptors-in-ejbs-through-interceptor-bindings Resolved as commit 43464. The EJBServices implementation of GlassFish was not handling duplicate Interceptor registrations. svn log -v -r 43464
        Hide
        Sivakumar Thyagarajan added a comment -

        svn log -v -r 43464

        Show
        Sivakumar Thyagarajan added a comment - svn log -v -r 43464
        Hide
        Sanjeeb Sahoo added a comment - - edited

        No, I am still seeing the issue. I am using a locally built glassfish corresponding to svn rev 43731, which is very latest. I don't see the interceptor getting called unless I add the interceptors explicitly in my EJB like this:

        @javax.interceptor.Interceptors(org.glassfish.cditest.security.interceptor.SecurityInterceptor.class)

        Given below are the messages in my server.log with the above workaround:

        [#|2010-12-13T08:53:29.810+0530|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=80;_ThreadName=admin-thread-pool-4848(2);|interceptor-ejb-cdi-test was successfully deployed in 693 milliseconds.|#]

        [#|2010-12-13T08:53:29.881+0530|INFO|glassfish3.1|org.glassfish.cditest.security.interceptor.SecurityInterceptor|_ThreadID=112;_ThreadName=http-thread-pool-8080(2);|EJB Method called [Full]:"javax.ejb" by Principal:ANONYMOUS|#]

        [#|2010-12-13T08:53:29.881+0530|INFO|glassfish3.1|org.glassfish.cditest.security.interceptor.SecurityInterceptor|_ThreadID=112;_ThreadName=http-thread-pool-8080(2);|EJB Method called [Methodonly]:findById by Principal:ANONYMOUS|#]

        [#|2010-12-13T08:53:29.881+0530|INFO|glassfish3.1|org.glassfish.cditest.user.api.UserService|_ThreadID=112;_ThreadName=http-thread-pool-8080(2);|Returning user UserImpl [id=0, emailAddress=test@test.org, firstName=John, gender=UNISEX, lastName=Doe, username=john-123]|#]

        Without the workaround, my log only contains:

        [#|2010-12-13T08:49:43.122+0530|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=82;_ThreadName=admin-thread-pool-4848(4);|interceptor-ejb-cdi-test was successfully deployed in 5,726 milliseconds.|#]

        [#|2010-12-13T08:50:10.275+0530|INFO|glassfish3.1|org.glassfish.cditest.user.api.UserService|_ThreadID=111;_ThreadName=http-thread-pool-8080(1);|Returning user UserImpl [id=0, emailAddress=test@test.org, firstName=John, gender=UNISEX, lastName=Doe, username=john-123]|#]

        Note the missing log lines for entries "EJB Method..." in the above output.

        Show
        Sanjeeb Sahoo added a comment - - edited No, I am still seeing the issue. I am using a locally built glassfish corresponding to svn rev 43731, which is very latest. I don't see the interceptor getting called unless I add the interceptors explicitly in my EJB like this: @javax.interceptor.Interceptors(org.glassfish.cditest.security.interceptor.SecurityInterceptor.class) Given below are the messages in my server.log with the above workaround: [#|2010-12-13T08:53:29.810+0530|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=80;_ThreadName=admin-thread-pool-4848(2);|interceptor-ejb-cdi-test was successfully deployed in 693 milliseconds.|#] [#|2010-12-13T08:53:29.881+0530|INFO|glassfish3.1|org.glassfish.cditest.security.interceptor.SecurityInterceptor|_ThreadID=112;_ThreadName=http-thread-pool-8080(2);|EJB Method called [Full] :"javax.ejb" by Principal:ANONYMOUS|#] [#|2010-12-13T08:53:29.881+0530|INFO|glassfish3.1|org.glassfish.cditest.security.interceptor.SecurityInterceptor|_ThreadID=112;_ThreadName=http-thread-pool-8080(2);|EJB Method called [Methodonly] :findById by Principal:ANONYMOUS|#] [#|2010-12-13T08:53:29.881+0530|INFO|glassfish3.1|org.glassfish.cditest.user.api.UserService|_ThreadID=112;_ThreadName=http-thread-pool-8080(2);|Returning user UserImpl [id=0, emailAddress=test@test.org, firstName=John, gender=UNISEX, lastName=Doe, username=john-123] |#] Without the workaround, my log only contains: [#|2010-12-13T08:49:43.122+0530|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=82;_ThreadName=admin-thread-pool-4848(4);|interceptor-ejb-cdi-test was successfully deployed in 5,726 milliseconds.|#] [#|2010-12-13T08:50:10.275+0530|INFO|glassfish3.1|org.glassfish.cditest.user.api.UserService|_ThreadID=111;_ThreadName=http-thread-pool-8080(1);|Returning user UserImpl [id=0, emailAddress=test@test.org, firstName=John, gender=UNISEX, lastName=Doe, username=john-123] |#] Note the missing log lines for entries "EJB Method..." in the above output.
        Hide
        Sivakumar Thyagarajan added a comment -

        There was a problem in the attached application. I had fixed it in my local setup to get it working and forgot to include it earlier.
        The application's beans.xml had the interceptors element commented out and hence no interceptors were enabled for that application. Similarly the application's beans.xml also had an older interceptor class-name.

        After making both these changes and redeploying the application, the "EJB Method ..." interceptor related lines appear. Diff for these changes is attached. I am closing this issue. Please reopen should you still see the issue. Thanks.

        Show
        Sivakumar Thyagarajan added a comment - There was a problem in the attached application. I had fixed it in my local setup to get it working and forgot to include it earlier. The application's beans.xml had the interceptors element commented out and hence no interceptors were enabled for that application. Similarly the application's beans.xml also had an older interceptor class-name. After making both these changes and redeploying the application, the "EJB Method ..." interceptor related lines appear. Diff for these changes is attached. I am closing this issue. Please reopen should you still see the issue. Thanks.
        Hide
        Sivakumar Thyagarajan added a comment -

        Attaching the working files and the diff to the original application

        Show
        Sivakumar Thyagarajan added a comment - Attaching the working files and the diff to the original application
        Hide
        chaoslayer added a comment -

        I made the changes mentioned (and understand why this was an issue) but I still get this exception when I try to separate security API, security interceptor implementation and the service EJB that should be secured into different bundles (this is with promoted b32):

        SEVERE: Exception while loading the app
        INFO: Deleted /tmp/osgiapp8129508894913510425
        SEVERE: Failed while deploying bundle org.glassfish.cditest.user.impl [281]
        WARNING: Failed to deploy bundle org.glassfish.cditest.user.impl [281]
        org.glassfish.osgijavaeebase.DeploymentException: Deployment of org.glassfish.cditest.user.impl [281] failed because of following reason: Failed while deploying bundle org.glassfish.cditest.user.impl [281] : java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.cditest.user.impl [281] ], root cause: Exception while loading the app
        at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:125)
        at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:147)
        at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:132)
        at org.glassfish.osgijavaeebase.JavaEEExtender.handleEvent(JavaEEExtender.java:117)
        at org.glassfish.osgijavaeebase.JavaEEExtender.access$000(JavaEEExtender.java:56)
        at org.glassfish.osgijavaeebase.JavaEEExtender$1.run(JavaEEExtender.java:100)
        Caused by: java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.cditest.user.impl [281] ], root cause: Exception while loading the app
        at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:196)
        at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
        at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
        ... 5 more
        Caused by: org.glassfish.deployment.common.DeploymentException: WELD-001417 Enabled interceptor class <class>org.glassfish.cditest.security.impl.SecurityInterceptor</class> in bundle://281.1:1/META-INF/beans.xml@8 is neither annotated @Interceptor nor registered through a portable extension
        at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:187)
        at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
        at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:302)
        at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
        at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
        at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:183)
        ... 7 more
        Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001417 Enabled interceptor class <class>org.glassfish.cditest.security.impl.SecurityInterceptor</class> in bundle://281.1:1/META-INF/beans.xml@8 is neither annotated @Interceptor nor registered through a portable extension
        at org.jboss.weld.bootstrap.Validator.validateEnabledInterceptorClasses(Validator.java:471)
        at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:344)
        at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:383)
        at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:184)
        ... 12 more

        Show
        chaoslayer added a comment - I made the changes mentioned (and understand why this was an issue) but I still get this exception when I try to separate security API, security interceptor implementation and the service EJB that should be secured into different bundles (this is with promoted b32): SEVERE: Exception while loading the app INFO: Deleted /tmp/osgiapp8129508894913510425 SEVERE: Failed while deploying bundle org.glassfish.cditest.user.impl [281] WARNING: Failed to deploy bundle org.glassfish.cditest.user.impl [281] org.glassfish.osgijavaeebase.DeploymentException: Deployment of org.glassfish.cditest.user.impl [281] failed because of following reason: Failed while deploying bundle org.glassfish.cditest.user.impl [281] : java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.cditest.user.impl [281] ], root cause: Exception while loading the app at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:125) at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:147) at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:132) at org.glassfish.osgijavaeebase.JavaEEExtender.handleEvent(JavaEEExtender.java:117) at org.glassfish.osgijavaeebase.JavaEEExtender.access$000(JavaEEExtender.java:56) at org.glassfish.osgijavaeebase.JavaEEExtender$1.run(JavaEEExtender.java:100) Caused by: java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.cditest.user.impl [281] ], root cause: Exception while loading the app at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:196) at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118) at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121) ... 5 more Caused by: org.glassfish.deployment.common.DeploymentException: WELD-001417 Enabled interceptor class <class>org.glassfish.cditest.security.impl.SecurityInterceptor</class> in bundle://281.1:1/META-INF/beans.xml@8 is neither annotated @Interceptor nor registered through a portable extension at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:187) at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128) at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:302) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:183) ... 7 more Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001417 Enabled interceptor class <class>org.glassfish.cditest.security.impl.SecurityInterceptor</class> in bundle://281.1:1/META-INF/beans.xml@8 is neither annotated @Interceptor nor registered through a portable extension at org.jboss.weld.bootstrap.Validator.validateEnabledInterceptorClasses(Validator.java:471) at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:344) at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:383) at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:184) ... 12 more
        Hide
        Sanjeeb Sahoo added a comment -

        Let's discuss the new issue in 15119.

        Show
        Sanjeeb Sahoo added a comment - Let's discuss the new issue in 15119.

          People

          • Assignee:
            Sivakumar Thyagarajan
            Reporter:
            Sanjeeb Sahoo
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: