glassfish
  1. glassfish
  2. GLASSFISH-599

JBI - Java EE Service Engine: java.lang.IllegalArgumentException

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 9.0pe
    • Fix Version/s: 9.0pe
    • Component/s: other
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      599

      Description

      Runtime: Java EE SDK Plus Build 44 with Manisha's fixes, and me changing the
      scenarios addAdjustmentJob, payRepairer and payCustomer to 2-way invokes.
      Design time: Seabiscuit (Coke Java Enterprise Pack)

      I run end-to-end the first time (first insurance claim) by sending the Business
      Process 1 message to exercise the 'receive' activity at
      http://localhost:20000/fileClaim and another message to exercise the 'receive'
      activity at http://localhost:20000/submitAdjustment. It works completely giving
      me a result as can be seen from the log entry below:

      [#|2006-04-24T01:08:55.754-0700|INFO|sun-appserver-pe9.0|javax.enterprise.system.stream.out|_ThreadID=17;_ThreadName=p:
      thread-pool-1; w: 3;| payCustomer with
      customerId:123456789::Chevrolet_Cavalier_2002::PersonalUse the amount of
      $8838.866|#]

      The second time I exercise the scenario, I get an IllegalArgumentException from
      the Java EE SE and its failing the call to getClaimNumber.

      I do not stop or shutdown anything now. I just want to try an end-to-end
      scenario again (by filing a second insurance claim).

      The second time I exercise the end-to-end scenario (to file a second insurance
      claim) by sending in the test message to http://localhost:20000/fileClaim, it
      blows up with an IllegalArgumentException from the Java EE SE. I cannot exercise
      an end-to-end scenario a second time.

      Subsequent tries to execute the scenario end-to-end fails with the same
      IllegalArgumentException from the Java EE SE.

      I tried restarting the AppServer and once again it works the first time - same
      as above. I can only file one insurance claim successfully.

      [#|2006-04-24T01:09:36.447-0700|INFO|sun-appserver-pe9.0|javax.enterprise.system.stream.out|_ThreadID=18;_ThreadName=p:
      thread-pool-1; w: 4;| Retrieving document at
      'C:/Sun/ApplicationServer/domains/domain1\generated\xml\j2ee-modules\InsuranceClaim\META-INF/wsdl/ClaimNumbererService.wsdl'.|#]

      [#|2006-04-24T01:09:36.447-0700|INFO|sun-appserver-pe9.0|javax.enterprise.system.stream.out|_ThreadID=18;_ThreadName=p:
      thread-pool-1; w: 4;| Retrieving schema at
      'http://192.168.0.196:8080/ClaimNumbererService/ClaimNumberer/__container$publishing$subctx/META-INF/wsdl/ClaimNumbererService_schema1.xsd',
      relative to
      'file:/C:/Sun/ApplicationServer/domains/domain1/generated/xml/j2ee-modules/InsuranceClaim/META-INF/wsdl/ClaimNumbererService.wsdl'.|#]

      [#|2006-04-24T01:09:36.467-0700|INFO|sun-appserver-pe9.0|com.sun.enterprise.jbi.serviceengine.util.soap|_ThreadID=18;_ThreadName=p:
      thread-pool-1; w: 4;|Denormalizing JBI Message into a SOAP Message|#]

      [#|2006-04-24T01:09:36.467-0700|INFO|sun-appserver-pe9.0|com.sun.enterprise.jbi.serviceengine.util.soap|_ThreadID=18;_ThreadName=p:
      thread-pool-1; w: 4;|Successfully denormalized response message|#]

      [#|2006-04-24T01:09:36.467-0700|SEVERE|sun-appserver-pe9.0|javax.enterprise.resource.webservices.jaxws.server.PeptTie|_ThreadID=18;_ThreadName=p:
      thread-pool-1; w: 4;_RequestID=97201f8a-6c74-4828-82a1-e3588137cb05;|object is
      not an instance of declaring class
      java.lang.IllegalArgumentException: object is not an instance of declaring class
      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:585)
      at
      com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1050)
      at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:165)
      at
      com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2766)
      at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3847)
      at
      com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:147)
      at $Proxy34.getClaimNumber(Unknown Source)
      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:585)
      at com.sun.xml.ws.server.PeptTie._invoke(PeptTie.java:58)
      at
      com.sun.xml.ws.protocol.soap.server.SOAPMessageDispatcher.invokeEndpoint(SOAPMessageDispatcher.java:278)
      at
      com.sun.xml.ws.protocol.soap.server.SOAPMessageDispatcher$SoapInvoker.invoke(SOAPMessageDispatcher.java:586)
      at
      com.sun.xml.ws.protocol.soap.server.SOAPMessageDispatcher.receive(SOAPMessageDispatcher.java:145)
      at com.sun.xml.ws.server.Tie.handle(Tie.java:88)
      at
      com.sun.enterprise.jbi.serviceengine.bridge.JAXWSMessageProcessor.doWork(JAXWSMessageProcessor.java:72)
      at
      com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:479)

      1. server.log
        45 kB
        gopalan
      1. insurance_processing.gif
        24 kB
      2. loan_processing.gif
        9 kB

        Activity

        Hide
        mu125243 added a comment -

        Hi Gopalan,

        Unfortunately I cann't get past the SOAP Binding itself and hence I am not able
        to reproduce the issue. I get Connection refused exception on the client side.
        Nothing shows up in server.log . Also please note that if I do netstat -a | grep
        <port-id> there is no socket opened on that port. The only difference between
        your environment and mine is Windows vs Linux.
        I used Java EE SDK plus bundle from following location.

        http://javaweb.sfbay/java/re/javaeesdk/5.0/nightly/bundles/latest/java_ee_sdk_plus-5-linux.bin

        (April 24th bundle).

        Regards,
        Manisha

        Show
        mu125243 added a comment - Hi Gopalan, Unfortunately I cann't get past the SOAP Binding itself and hence I am not able to reproduce the issue. I get Connection refused exception on the client side. Nothing shows up in server.log . Also please note that if I do netstat -a | grep <port-id> there is no socket opened on that port. The only difference between your environment and mine is Windows vs Linux. I used Java EE SDK plus bundle from following location. http://javaweb.sfbay/java/re/javaeesdk/5.0/nightly/bundles/latest/java_ee_sdk_plus-5-linux.bin (April 24th bundle). Regards, Manisha
        Hide
        gopalan added a comment -

        Created an attachment (id=240)
        Here's the Service Assembly created on a Solaris/Sparc machine using the latest Seabiscuit build. Exhibits the same problem

        Show
        gopalan added a comment - Created an attachment (id=240) Here's the Service Assembly created on a Solaris/Sparc machine using the latest Seabiscuit build. Exhibits the same problem
        Hide
        gopalan added a comment -

        Created an attachment (id=241)
        Solaris/Sparc project artifacts - In case you want to re-create the entire design-time scenario.

        Show
        gopalan added a comment - Created an attachment (id=241) Solaris/Sparc project artifacts - In case you want to re-create the entire design-time scenario.
        Hide
        binod added a comment -

        The com.sun.ejb.containers.WebServiceInvocationHandler uses the ejb instance
        from the invocation context. The invocation context is populated when the
        RuntimeEndpointInfo is populated by the service engine.

        Look like the cleanup of the invocation context was not happening properly.
        So, when threads gets reused the operation is executed against a different EJB
        instance.

        Following is the fix for the issue. With this the demo is executing properly now.

        Index: bridge/RuntimeEndpointInfoRegistryImpl.java
        ===================================================================
        RCS file:
        /cvs/glassfish/appserv-addons/jbi/src/java/com/sun/enterprise/jbi/serviceengine/bridge/RuntimeEndpointInfoRegistryImpl.java,v
        retrieving revision 1.7
        diff -r1.7 RuntimeEndpointInfoRegistryImpl.java
        77a78,81
        > } else {
        > if(endpt.isJAXWSEndpoint() && endpt.isImplementedByEJB())

        { > runtimeInfo = JAXWSRuntimeEndpointHelper.populateRuntimeInfo(endpt); > }
        Show
        binod added a comment - The com.sun.ejb.containers.WebServiceInvocationHandler uses the ejb instance from the invocation context. The invocation context is populated when the RuntimeEndpointInfo is populated by the service engine. Look like the cleanup of the invocation context was not happening properly. So, when threads gets reused the operation is executed against a different EJB instance. Following is the fix for the issue. With this the demo is executing properly now. Index: bridge/RuntimeEndpointInfoRegistryImpl.java =================================================================== RCS file: /cvs/glassfish/appserv-addons/jbi/src/java/com/sun/enterprise/jbi/serviceengine/bridge/RuntimeEndpointInfoRegistryImpl.java,v retrieving revision 1.7 diff -r1.7 RuntimeEndpointInfoRegistryImpl.java 77a78,81 > } else { > if(endpt.isJAXWSEndpoint() && endpt.isImplementedByEJB()) { > runtimeInfo = JAXWSRuntimeEndpointHelper.populateRuntimeInfo(endpt); > }
        Hide
        binod added a comment -

        Fix has been checked in to FCS branch and trunk.

        Show
        binod added a comment - Fix has been checked in to FCS branch and trunk.

          People

          • Assignee:
            binod
            Reporter:
            gopalan
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: