glassfish
  1. glassfish
  2. GLASSFISH-16196

@OSGIService causes ClassCastException in OSGiServiceFactory$StaticInvocationHandler or OSGiServiceFactory.lookupService

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.1
    • Fix Version/s: 3.1.1
    • Component/s: cdi, OSGi-JavaEE
    • Labels:
      None
    • Environment:

      Ubuntu 10.10, x64

      Description

      Given the following code snippet:

      @WebService(targetNamespace="http://www.asml.com/otas/data-manager")
      @SOAPBinding(parameterStyle=ParameterStyle.WRAPPED, style=Style.DOCUMENT, use=Use.LITERAL)
      public class DataManagerWebService {

      @Inject
      @OSGiService(dynamic=true)
      DataManager dataManagerService;
      ...
      }

      DataManager is defined in another bundle deployed succesfully on GlassFish.

      In case I deploy the WAR containing the above JAX-WS web service classas an OSGi bundle, injection works as expected.

      In case I deploy the WAR as a non-OSGi bundle (i.e. just as a regular WAR), I get class cast exceptions. This is both when using dynamic=true or dynamic=false, though the place where the exception occurs differs. See the stack traces below.

      Expected behaviour: injection of OSGi Services should work transparent for both OSGi and non-OSGI WAR bundles. Though untested, I presume the same issue is present for e.g EJB and Servlet components.

      Impact: high. We work from an Eclipse environment, where deploying OSGi bundles on a standard Glassfish container is not yet possible given the default Eclipse-Glassfish plugin. Being able to deploy OSGi WARs as regular WARs would greatly alleviate this short-comming. Glassfish is currently being evaluated as a future platform for migration (from Tomcat). Seamless OSGi/JavaEE integration is a high-priority requirement for us.

      dynamic=true stacktrace:

      [#|2011-03-11T17:48:33.439+0100|SEVERE|glassfish3.1|com.sun.xml.ws.server.sei.EndpointMethodHandler|_ThreadID=20;_ThreadName=Thread-1;|The log message is null.
      java.lang.ClassCastException
      at java.lang.Class.cast(Class.java:2990)
      at org.glassfish.osgicdi.impl.OSGiServiceFactory.lookupService(OSGiServiceFactory.java:110)
      at org.glassfish.osgicdi.impl.OSGiServiceFactory.access$100(OSGiServiceFactory.java:67)
      at org.glassfish.osgicdi.impl.OSGiServiceFactory$DynamicInvocationHandler.invoke(OSGiServiceFactory.java:183)
      at $Proxy264.deleteDocument(Unknown Source)
      at com.asml.de.otas.dama.webservice.DataManagerWebService.deleteDocument(DataManagerWebService.java:58)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at org.glassfish.webservices.InstanceResolverImpl$1.invoke(InstanceResolverImpl.java:143)
      at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:150)
      at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:261)
      at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:100)
      ...

      dynamic=false stacktrace:

      Caused by: java.lang.ClassCastException
      at java.lang.Class.cast(Class.java:2990)
      at org.glassfish.osgicdi.impl.OSGiServiceFactory$StaticInvocationHandler.getBundleContext(OSGiServiceFactory.java:212)
      at org.glassfish.osgicdi.impl.OSGiServiceFactory$StaticInvocationHandler.<init>(OSGiServiceFactory.java:206)
      at org.glassfish.osgicdi.impl.OSGiServiceFactory.createServiceProxy(OSGiServiceFactory.java:90)
      at org.glassfish.osgicdi.impl.OSGiServiceFactory.getService(OSGiServiceFactory.java:79)
      at org.glassfish.osgicdi.impl.OSGiServiceExtension$OSGiServiceBean.create(OSGiServiceExtension.java:242)
      at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:67)
      at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:690)
      ....

        Activity

        Hide
        Sivakumar Thyagarajan added a comment -

        Analysis: In OSGiServiceFactory, we do not handle the scenario where the annotated injection point is in a non-OSGi bundle(regular WAR). So, in 3.1.1, at a minimum we should investigate modifying the error message to indicate that injection is attempted in a non-OSGi bundle.

        Show
        Sivakumar Thyagarajan added a comment - Analysis: In OSGiServiceFactory, we do not handle the scenario where the annotated injection point is in a non-OSGi bundle(regular WAR). So, in 3.1.1, at a minimum we should investigate modifying the error message to indicate that injection is attempted in a non-OSGi bundle.
        Hide
        Sivakumar Thyagarajan added a comment -

        Component Name: OSGi-CDI
        Issue: http://java.net/jira/browse/GLASSFISH-16196

        • Why fix this issue in 3.1.1?

        Affects scenarios where a OSGi/CDI injection is expected on a non-OSGi archive. Please see bug report for more information.

        • Which is the targeted build of 3.1.1 for this fix?

        3.1.1 b08

        • Do regression tests exist for this issue?

        I will add a regression test to the CDI developer test suite.

        • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

        Regression test added to the CDI developer test suite.

        Show
        Sivakumar Thyagarajan added a comment - Component Name: OSGi-CDI Issue: http://java.net/jira/browse/GLASSFISH-16196 Why fix this issue in 3.1.1? Affects scenarios where a OSGi/CDI injection is expected on a non-OSGi archive. Please see bug report for more information. Which is the targeted build of 3.1.1 for this fix? 3.1.1 b08 Do regression tests exist for this issue? I will add a regression test to the CDI developer test suite. Which tests should QA (re)run to verify the fix did not destabilize GlassFish? Regression test added to the CDI developer test suite.
        Hide
        Sivakumar Thyagarajan added a comment -

        Fix checked in FighterFish as part of

        Sending osgi-cdi/src/main/java/org/glassfish/osgicdi/impl/OSGiServiceExtension.java
        Sending osgi-cdi/src/main/java/org/glassfish/osgicdi/impl/OSGiServiceFactory.java
        Transmitting file data ..
        Committed revision 47617.

        Will mark as committed when the next version of FighterFish is integrated into 3.1.1 and trunk.

        Show
        Sivakumar Thyagarajan added a comment - Fix checked in FighterFish as part of Sending osgi-cdi/src/main/java/org/glassfish/osgicdi/impl/OSGiServiceExtension.java Sending osgi-cdi/src/main/java/org/glassfish/osgicdi/impl/OSGiServiceFactory.java Transmitting file data .. Committed revision 47617. Will mark as committed when the next version of FighterFish is integrated into 3.1.1 and trunk.
        Hide
        Sivakumar Thyagarajan added a comment -

        Integrated org.glassfish.fighterfish:osgi-cdi 1.0.1 to trunk (svn rev 47637) and 3.1.1(svn rev 47636) to fix this issue.

        Show
        Sivakumar Thyagarajan added a comment - Integrated org.glassfish.fighterfish:osgi-cdi 1.0.1 to trunk (svn rev 47637) and 3.1.1(svn rev 47636) to fix this issue.
        Hide
        Sivakumar Thyagarajan added a comment -

        Marked fix version as 3.1.1

        Show
        Sivakumar Thyagarajan added a comment - Marked fix version as 3.1.1

          People

          • Assignee:
            Sivakumar Thyagarajan
            Reporter:
            jbenckhuijsen
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: