glassfish
  1. glassfish
  2. GLASSFISH-15119

CDI Interceptor still not working in OSGi

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1_b31
    • Fix Version/s: future release
    • Component/s: cdi, OSGi-JavaEE
    • Labels:
      None
    • Environment:

      Tested with promoted b32

      Description

      I just revisited GLASSFISH-13513 and GLASSFISH-14831 to see if it is possible to plug in interceptors the CDI way around EJBs.

      Indeed when deploying a prepared package as non-OSGi the interceptor gets invoked but not when using OSGi deployment.

      Therefore I made up another test case which should be sufficient for a confirmation of this issue:

      • maven reactor build with 4 modules
      • build.sh script for test:
      • "mvn clean install"
      • copy resulting artifacts into .../autodeploy/bundles/ folder of a running glassfish domain
      • wait for (re-)deployment
      • using "curl" to call the web service
      • search for a fault inside the returned XML

      So basically for a test I issue a command like this:

      $ GF_DOMAIN_DIR=/srv/servers/gf-3.1-b32/glassfish/domains/domain1/ ./build.sh

      Well, I also can say that with the old @Interceptors(

      {SecurityInterceptor.class}

      ) method the interceptor is being called so I suspect it is not injected at all.

      This test throws a fault if the interceptor is being invoked. If no fault occurs and the response is valid there must be something wrong.

      1. interceptor-osgi-test.tar.bz2
        6 kB
        Sivakumar Thyagarajan
      2. interceptor-osgi-test-2.tar.gz
        8 kB
        chaoslayer
      3. interceptor-osgi-test-2-fixed.tar.gz
        8 kB
        chaoslayer

        Issue Links

          Activity

          Hide
          chaoslayer added a comment -

          Thanks for reopening the issue, I was not allowed to.

          Show
          chaoslayer added a comment - Thanks for reopening the issue, I was not allowed to.
          Hide
          Sanjeeb Sahoo added a comment -

          Assigning this to cdi team after talking to Siva. It is a bug in their layer.

          Show
          Sanjeeb Sahoo added a comment - Assigning this to cdi team after talking to Siva. It is a bug in their layer.
          Hide
          chaoslayer added a comment -

          Fixed the project and enabled interceptor class in beans.xml for the user service [interceptor-osgi-test-2-fixed.tar.gz].

          Just tested again with a completely clean b32:

          INFO: Portable JNDI names for EJB UserServiceImpl : [java:global/org.glassfish.cditest.user.service_2.0.0.SNAPSHOT/UserServiceImpl!org.glassfish.cditest.user.api.UserService, java:global/org.glassfish.cditest.user.service_2.0.0.SNAPSHOT/UserServiceImpl]
          INFO: WELD-000900 $

          {parsedVersion (osgiVersion}

          )
          INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
          SEVERE: Exception while loading the app
          INFO: Deleted /tmp/osgiapp5600363451663621402
          SEVERE: Failed while deploying bundle org.glassfish.cditest.user.service [252]
          WARNING: Failed to deploy bundle org.glassfish.cditest.user.service [252]
          org.glassfish.osgijavaeebase.DeploymentException: Deployment of org.glassfish.cditest.user.service [252] failed because of following reason: Failed while deploying bundle org.glassfish.cditest.user.service [252] : java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.cditest.user.service [252] ], 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.service [252] ], 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.interceptor.SecurityInterceptor</class> in bundle://252.0: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.interceptor.SecurityInterceptor</class> in bundle://252.0: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

          So I guess it has to do with class visibility here. Although all required classes are visible for the bundle it may once again be a deployment issue:

          250|Active | 1|Apache Felix Bundle Repository (1.6.2)
          251|Active | 1|OSGi/JTA implementation in GlassFish (3.1.0.b32)
          252|Active | 1|User Service OSGi Bundle (2.0.0.SNAPSHOT)
          253|Active | 1|User Web Service OSGi Web Service (2.0.0.SNAPSHOT)
          254|Active | 1|security.impl OSGi Bundle (2.0.0.SNAPSHOT)
          255|Active | 1|security.api OSGi Bundle (2.0.0.SNAPSHOT)
          g! inspect p c 255
          org.glassfish.cditest.security.api [255] exports packages:
          ----------------------------------------------------------
          org.glassfish.cditest.security.api; version=0.0.0 imported by:
          org.glassfish.cditest.user.service [252]
          org.glassfish.cditest.security.impl [254]
          g! inspect p c 254
          org.glassfish.cditest.security.impl [254] exports packages:
          -----------------------------------------------------------
          org.glassfish.cditest.security.interceptor; version=0.0.0 imported by:
          org.glassfish.cditest.user.service [252]
          g! inspect p r 252
          org.glassfish.cditest.user.service [252] imports packages:
          ----------------------------------------------------------
          javax.ejb; version=3.1.0 -> org.glassfish.javax.ejb [171]
          org.glassfish.cditest.security.interceptor; version=0.0.0 -> org.glassfish.cditest.security.impl [254]
          org.glassfish.cditest.security.api; version=0.0.0 -> org.glassfish.cditest.security.api [255]

          Show
          chaoslayer added a comment - Fixed the project and enabled interceptor class in beans.xml for the user service [interceptor-osgi-test-2-fixed.tar.gz] . Just tested again with a completely clean b32: INFO: Portable JNDI names for EJB UserServiceImpl : [java:global/org.glassfish.cditest.user.service_2.0.0.SNAPSHOT/UserServiceImpl!org.glassfish.cditest.user.api.UserService, java:global/org.glassfish.cditest.user.service_2.0.0.SNAPSHOT/UserServiceImpl] INFO: WELD-000900 $ {parsedVersion (osgiVersion} ) INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver. SEVERE: Exception while loading the app INFO: Deleted /tmp/osgiapp5600363451663621402 SEVERE: Failed while deploying bundle org.glassfish.cditest.user.service [252] WARNING: Failed to deploy bundle org.glassfish.cditest.user.service [252] org.glassfish.osgijavaeebase.DeploymentException: Deployment of org.glassfish.cditest.user.service [252] failed because of following reason: Failed while deploying bundle org.glassfish.cditest.user.service [252] : java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.cditest.user.service [252] ], 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.service [252] ], 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.interceptor.SecurityInterceptor</class> in bundle://252.0: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.interceptor.SecurityInterceptor</class> in bundle://252.0: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 So I guess it has to do with class visibility here. Although all required classes are visible for the bundle it may once again be a deployment issue: 250|Active | 1|Apache Felix Bundle Repository (1.6.2) 251|Active | 1|OSGi/JTA implementation in GlassFish (3.1.0.b32) 252|Active | 1|User Service OSGi Bundle (2.0.0.SNAPSHOT) 253|Active | 1|User Web Service OSGi Web Service (2.0.0.SNAPSHOT) 254|Active | 1|security.impl OSGi Bundle (2.0.0.SNAPSHOT) 255|Active | 1|security.api OSGi Bundle (2.0.0.SNAPSHOT) g! inspect p c 255 org.glassfish.cditest.security.api [255] exports packages: ---------------------------------------------------------- org.glassfish.cditest.security.api; version=0.0.0 imported by: org.glassfish.cditest.user.service [252] org.glassfish.cditest.security.impl [254] g! inspect p c 254 org.glassfish.cditest.security.impl [254] exports packages: ----------------------------------------------------------- org.glassfish.cditest.security.interceptor; version=0.0.0 imported by: org.glassfish.cditest.user.service [252] g! inspect p r 252 org.glassfish.cditest.user.service [252] imports packages: ---------------------------------------------------------- javax.ejb; version=3.1.0 -> org.glassfish.javax.ejb [171] org.glassfish.cditest.security.interceptor; version=0.0.0 -> org.glassfish.cditest.security.impl [254] org.glassfish.cditest.security.api; version=0.0.0 -> org.glassfish.cditest.security.api [255]
          Hide
          Sanjeeb Sahoo added a comment -

          I discussed with our CDI engineer (sivakumar) and he thinks there is more to it than classloading. He thinks this can be reproduced without use of OSGi as well. He is looking into it.

          Show
          Sanjeeb Sahoo added a comment - I discussed with our CDI engineer (sivakumar) and he thinks there is more to it than classloading. He thinks this can be reproduced without use of OSGi as well. He is looking into it.
          Hide
          chaoslayer added a comment -

          OK, so do you need any additional data from my side?

          Show
          chaoslayer added a comment - OK, so do you need any additional data from my side?
          Hide
          Sanjeeb Sahoo added a comment -

          No, not at this point. We have sufficient information to proceed. Thanks.

          Show
          Sanjeeb Sahoo added a comment - No, not at this point. We have sufficient information to proceed. Thanks.
          Hide
          Sanjeeb Sahoo added a comment -

          Needed for 3.1

          Show
          Sanjeeb Sahoo added a comment - Needed for 3.1
          Hide
          Sivakumar Thyagarajan added a comment -

          Modified testcase with the following changes:
          1. brought the interceptor enablement to security.impl and 2. removed the interceptor enablement in user.impl

          The interceptor class is defined in security.impl and must be enabled there.

          Show
          Sivakumar Thyagarajan added a comment - Modified testcase with the following changes: 1. brought the interceptor enablement to security.impl and 2. removed the interceptor enablement in user.impl The interceptor class is defined in security.impl and must be enabled there.
          Hide
          Sivakumar Thyagarajan added a comment -

          While debugging this issue, we noticed that the interceptor was enabled in the user.impl bundle. The interceptor is defined in the security.impl bundle and hence has to be enabled there. Attached the modified test-case that has these changes. With these changes, the 3 bundles deploy in GF3.1 latest trunk.

          However there is an issue. GF3.1 considers the first two bundles (security.api and security.impl) as plain vanilla OSGi bundles (not EE archives) and hence are not considered as CDI archives. Furthermore, since there is no "explicit" relationship (apart from the usage of the CDI interceptor binding) between the user.impl and the other two bundles, when the user.impl WAB is deployed, the user.impl WAB "alone" is considered as a CDI archive. The CDI runtime does not have access to the Beans in security.api/security.impl and hence this usecase will not work. GF3.1 CDI-OSGi support should support scenarios where the Beans used by a bundle are in a different bundle and scenarios where Beans could exist in plain vanilla osgi bundles. I have raised a RFE, GLASSFISH-15249, for this and targetted this for 3.2 as it is more involved to be considered for 3.1.

          Here are two possible workarounds:

          • One bundle: Bundling all the Beans together in user.impl (ie have one bundle and not 3 bundles) would work. I don't know if this works for you, though.
          • Fragment bundle approach: I had a discussion with Sahoo and he is investigating the use of security.api and security.impl as fragment bundles as a workaround, and he will update this thread with his finding.
          Show
          Sivakumar Thyagarajan added a comment - While debugging this issue, we noticed that the interceptor was enabled in the user.impl bundle. The interceptor is defined in the security.impl bundle and hence has to be enabled there. Attached the modified test-case that has these changes. With these changes, the 3 bundles deploy in GF3.1 latest trunk. However there is an issue. GF3.1 considers the first two bundles (security.api and security.impl) as plain vanilla OSGi bundles (not EE archives) and hence are not considered as CDI archives. Furthermore, since there is no "explicit" relationship (apart from the usage of the CDI interceptor binding) between the user.impl and the other two bundles, when the user.impl WAB is deployed, the user.impl WAB "alone" is considered as a CDI archive. The CDI runtime does not have access to the Beans in security.api/security.impl and hence this usecase will not work. GF3.1 CDI-OSGi support should support scenarios where the Beans used by a bundle are in a different bundle and scenarios where Beans could exist in plain vanilla osgi bundles. I have raised a RFE, GLASSFISH-15249 , for this and targetted this for 3.2 as it is more involved to be considered for 3.1. Here are two possible workarounds: One bundle: Bundling all the Beans together in user.impl (ie have one bundle and not 3 bundles) would work. I don't know if this works for you, though. Fragment bundle approach: I had a discussion with Sahoo and he is investigating the use of security.api and security.impl as fragment bundles as a workaround, and he will update this thread with his finding.
          Hide
          Sivakumar Thyagarajan added a comment -

          Raised a RFE GLASSFISH-15249 to fix the underlying usecase.

          Show
          Sivakumar Thyagarajan added a comment - Raised a RFE GLASSFISH-15249 to fix the underlying usecase.
          Hide
          chaoslayer added a comment -

          Well, not quite covering our use case scenario. Let me explain what we "want":

          • we have one Security API bundle that contains the @Secure interface
          • we have one or more Security implementation bundles that contain the implementation for @Secure
          • we have around 20 EJB bundles that have to be "secured" via the CDI interceptor binding

          So workaround one effectively disables OSGi here completely and pulls in a lot of work todo for our setup, from building to integration testing to deployment.

          Option two could be an option, although I think only the bundle that contains the interceptor should be made available as a fragment bundle attaching to all those EJB bundles.

          But what happens if not all Fragement-Hosts are available for the interceptor fragment bundle? Is it still resolved for those that are available? The spec is somewhat unclear here. The use case here is of course modularity. As our developers are working in different areas of interest they only use the bundles that they need. Security is a very basic need but should support those scenarios without modification at build time.

          Thanks for the RFE, btw.

          Show
          chaoslayer added a comment - Well, not quite covering our use case scenario. Let me explain what we "want": we have one Security API bundle that contains the @Secure interface we have one or more Security implementation bundles that contain the implementation for @Secure we have around 20 EJB bundles that have to be "secured" via the CDI interceptor binding So workaround one effectively disables OSGi here completely and pulls in a lot of work todo for our setup, from building to integration testing to deployment. Option two could be an option, although I think only the bundle that contains the interceptor should be made available as a fragment bundle attaching to all those EJB bundles. But what happens if not all Fragement-Hosts are available for the interceptor fragment bundle? Is it still resolved for those that are available? The spec is somewhat unclear here. The use case here is of course modularity. As our developers are working in different areas of interest they only use the bundles that they need. Security is a very basic need but should support those scenarios without modification at build time. Thanks for the RFE, btw.
          Hide
          Sanjeeb Sahoo added a comment -

          Yes, I just tried by converting security.impl to be a fragment of user.impl and having the <interceptors> element defined in user.impl's beans.xml. With this, I am able to see the interceptors in action. I realize this is not an optimal solution, but looks like a work around to me.

          Show
          Sanjeeb Sahoo added a comment - Yes, I just tried by converting security.impl to be a fragment of user.impl and having the <interceptors> element defined in user.impl's beans.xml. With this, I am able to see the interceptors in action. I realize this is not an optimal solution, but looks like a work around to me.
          Hide
          Sanjeeb Sahoo added a comment -

          A fragment can't be attached to more than one host, so there is a potential issue for your use case. Let us think more.

          Show
          Sanjeeb Sahoo added a comment - A fragment can't be attached to more than one host, so there is a potential issue for your use case. Let us think more.
          Hide
          Sivakumar Thyagarajan added a comment -

          Marking as "3_1-exclude" and targetting for 3.2

          Show
          Sivakumar Thyagarajan added a comment - Marking as "3_1-exclude" and targetting for 3.2
          Hide
          Sivakumar Thyagarajan added a comment -

          Marking as 3_1-next as this was targetted for 3.1+ releases

          Show
          Sivakumar Thyagarajan added a comment - Marking as 3_1-next as this was targetted for 3.1+ releases
          Hide
          Sivakumar Thyagarajan added a comment -

          Marked issue as "Major"

          Show
          Sivakumar Thyagarajan added a comment - Marked issue as "Major"
          Hide
          Sivakumar Thyagarajan added a comment -

          Moving a fix for this to a "future release" as the dependent issue GLASSFISH-15249 is also moved.

          There is a workaround for this issue as Sahoo points out above.

          Show
          Sivakumar Thyagarajan added a comment - Moving a fix for this to a "future release" as the dependent issue GLASSFISH-15249 is also moved. There is a workaround for this issue as Sahoo points out above.
          Hide
          TangYong added a comment -

          siva, sahoo,

          Please add a osgi-javaee component for the issue.

          Show
          TangYong added a comment - siva, sahoo, Please add a osgi-javaee component for the issue.
          Hide
          TangYong added a comment -

          Because the bug depends on GLASSFISH-15249 which will be implemented in future release, fix version is adjusted into future release.

          Show
          TangYong added a comment - Because the bug depends on GLASSFISH-15249 which will be implemented in future release, fix version is adjusted into future release.

            People

            • Assignee:
              mtaube
              Reporter:
              chaoslayer
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: