Beehive
  1. Beehive
  2. BEEHIVE-769

WSM client control can not load WSDL file from @WSDL annotation

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: v1m1
    • Fix Version/s: 1.0.2
    • Component/s: System Controls
    • Labels:
      None
    • Environment:
      Win XP SP2, JDK 1.5.03

      Description

      In WSM web service client control, I specified @WSDL(path="Skugen.wsdl"...) as I did before. But latest unit test failed with following error:

      -------------------------------------------------------------------------
      bcc
      java.lang.NullPointerException: bcc
      at java.beans.beancontext.BeanContextSupport.getResourceAsStream(BeanContextSupport.java:646)
      at org.apache.beehive.controls.system.webservice.jaxrpc.ServiceControlImpl.getWSDLStream(ServiceControlImpl.java:514)
      at org.apache.beehive.controls.system.webservice.jaxrpc.ServiceControlImpl.initialize(ServiceControlImpl.java:457)
      at org.apache.beehive.controls.system.webservice.jaxrpc.ServiceControlImpl.invoke(ServiceControlImpl.java:126)
      at com.bea.wlw.aa.skugen.ws.GenerateSKUBean.ping(GenerateSKUBean.java:124)
      at com.bea.wlw.aa.skugen.ws.SkuGeneratorClientControlTest.testPing(SkuGeneratorClientControlTest.java:80)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at

      ----------------------------------------------------------------------------

      According to stack trace. In source code:
      org.apache.beehive.controls.system.webservice.jaxrpc.ServiceControlImpl.java,
      the private method getWSDLStream(String), at line 514:

      wsdlStream =cbContext.getBeanContext().getResourceAsStream(pathToWSDL, null);

      The second parameter is "null". But by checking JDK source code 1.5.03 in
      java.beans.beancontext.BeanContextSupport.java, at line 644, the method:

      public InputStream getResourceAsStream(String name, BeanContextChild bcc) {
      if (name == null) throw new NullPointerException("name");
      if (bcc == null) throw new NullPointerException("bcc");

      if (containsKey(bcc))

      { ClassLoader cl = bcc.getClass().getClassLoader(); return cl != null ? cl.getResourceAsStream(name) : ClassLoader.getSystemResourceAsStream(name); }

      else throw new IllegalArgumentException("Not a valid child");
      }

      "bcc" is required somehow, that is why the NullPointerException happened.

        Activity

        Hide
        Rich Feit added a comment -

        This seems like it might be critical enough to hold the release (and cause a re-vote on a new revision). Can someone comment on this, and also on the risk/complexity of the fix?

        Show
        Rich Feit added a comment - This seems like it might be critical enough to hold the release (and cause a re-vote on a new revision). Can someone comment on this, and also on the risk/complexity of the fix?
        Hide
        Rich Feit added a comment -

        Also, Yongqin, would you attach the repro case? It looks like this will always blow up if the WSDL path is local (as opposed to a URI).

        Would you also include the last revision number you know was working OK? If you don't have that, a rough date would still be helpful. It looks like the suspect revision is 170192, but I'd like to confirm.

        Show
        Rich Feit added a comment - Also, Yongqin, would you attach the repro case? It looks like this will always blow up if the WSDL path is local (as opposed to a URI). Would you also include the last revision number you know was working OK? If you don't have that, a rough date would still be helpful. It looks like the suspect revision is 170192, but I'd like to confirm.
        Hide
        Rich Feit added a comment -

        Daryoush, it looks like revision 170192 was a patch that you contributed. Would you take a look and attach a proposed fix?

        Thanks,
        Rich

        Show
        Rich Feit added a comment - Daryoush, it looks like revision 170192 was a patch that you contributed. Would you take a look and attach a proposed fix? Thanks, Rich
        Hide
        daryoush mehrtash added a comment -

        The problem here is that the control is not initialized correctly. The fact that the calls ends up in java.beans.beancontext.BeanContextSupport.java means that you don't have the correct bean context. If the control is running in a container then there is a problem in the container initialization. If the control is running in the JUnit environment, you need to make sure your are initializing the controls properly.

        The best place to look at a running example of the controls in Junit context is the controls-webservices-blank in the distribution samples. The sample runs a service control against the wsm-addressbook-enhanced (that is also in the samples) web service. To run the controls-webservices-blank you need to make sure to have built and deployed the wsm-addressbook-enhanced.

        There are two changes you need to be aware of:: Build process, and Controls initialization in JUnit (if you are running the control as JUnit)

        Take a look at the build.xml for the . controls-webservices-blank and notice that there has been a change in the arguments to the ExtensionMaker. The "-wsdl_path_annotation ." argument is not longer used. You should only need:

        <arg line="-gen_root $

        {gen.source.dir}

        -wsdl $

        {schema.dir}

        -pkg $

        {my.service.control.package}

        " />

        At run time The JCX file and the WSDL file should be on the same directory and in the JCX file your @WSDL annotations should look like:

        @WSDL(path = "Service.wsdl",
        service = "EnhancedAddressBook")

        Notice the "./" is no longer used in the path.

        Junit Initalization.....I suspect this is the main source of your problem. Please look at the controls-webservices-blank 's junit\test\AddressBookTest.java. Notice the "setup()" and "teardown()" methods that perform the control initializations and install the correct context. The Service Control Drt Tests also uses a similar structure in the unit testing. You need to make sure your unit tests also perform similar steps.

        Hope this help. I leave the bug open until we make sure this would fix your problem.

        Show
        daryoush mehrtash added a comment - The problem here is that the control is not initialized correctly. The fact that the calls ends up in java.beans.beancontext.BeanContextSupport.java means that you don't have the correct bean context. If the control is running in a container then there is a problem in the container initialization. If the control is running in the JUnit environment, you need to make sure your are initializing the controls properly. The best place to look at a running example of the controls in Junit context is the controls-webservices-blank in the distribution samples. The sample runs a service control against the wsm-addressbook-enhanced (that is also in the samples) web service. To run the controls-webservices-blank you need to make sure to have built and deployed the wsm-addressbook-enhanced. There are two changes you need to be aware of:: Build process, and Controls initialization in JUnit (if you are running the control as JUnit) Take a look at the build.xml for the . controls-webservices-blank and notice that there has been a change in the arguments to the ExtensionMaker. The "-wsdl_path_annotation ." argument is not longer used. You should only need: <arg line="-gen_root $ {gen.source.dir} -wsdl $ {schema.dir} -pkg $ {my.service.control.package} " /> At run time The JCX file and the WSDL file should be on the same directory and in the JCX file your @WSDL annotations should look like: @WSDL(path = "Service.wsdl", service = "EnhancedAddressBook") Notice the "./" is no longer used in the path. Junit Initalization.....I suspect this is the main source of your problem. Please look at the controls-webservices-blank 's junit\test\AddressBookTest.java. Notice the "setup()" and "teardown()" methods that perform the control initializations and install the correct context. The Service Control Drt Tests also uses a similar structure in the unit testing. You need to make sure your unit tests also perform similar steps. Hope this help. I leave the bug open until we make sure this would fix your problem.
        Hide
        Rich Feit added a comment -

        Thanks for the investigation and explanation. I think that if this turns out to have been the issue, then we should lower the priority of this bug and push it to TBD, in order to get a better error if there's not a properly-initialized context. This particular NPE is pretty hard to figure out. Sounds like we're OK for the release, though.

        Show
        Rich Feit added a comment - Thanks for the investigation and explanation. I think that if this turns out to have been the issue, then we should lower the priority of this bug and push it to TBD, in order to get a better error if there's not a properly-initialized context. This particular NPE is pretty hard to figure out. Sounds like we're OK for the release, though.
        Hide
        daryoush mehrtash added a comment -

        I have change the bug to a feature request for the next version to improve on the error message.

        Show
        daryoush mehrtash added a comment - I have change the bug to a feature request for the next version to improve on the error message.
        Hide
        Chad Schoettger added a comment -

        moved to system controls category

        Show
        Chad Schoettger added a comment - moved to system controls category
        Hide
        Chad Schoettger added a comment -

        This bug should be resolved. A fair amout of work has went into cleaning up how the wsdl is loaded from the information provided in the WSDL annotation.

        Show
        Chad Schoettger added a comment - This bug should be resolved. A fair amout of work has went into cleaning up how the wsdl is loaded from the information provided in the WSDL annotation.

          People

          • Assignee:
            Jacob Danner
            Reporter:
            Yongqin Xu
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development