beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "daryoush mehrtash (JIRA)" <>
Subject [jira] Commented: (BEEHIVE-769) WSM client control can not load WSDL file from @WSDL annotation
Date Fri, 27 May 2005 20:16:12 GMT
     [ ]
daryoush mehrtash commented on BEEHIVE-769:

The problem here is that the control is not initialized correctly.  The fact that the calls
ends up in 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\  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.

> WSM client control can not load WSDL file from @WSDL annotation
> ---------------------------------------------------------------
>          Key: BEEHIVE-769
>          URL:
>      Project: Beehive
>         Type: Bug
>   Components: Controls
>     Versions: V1
>  Environment: Win XP SP2, JDK 1.5.03
>     Reporter: Yongqin Xu
>     Assignee: daryoush mehrtash
>     Priority: Critical

> 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(
> 	at org.apache.beehive.controls.system.webservice.jaxrpc.ServiceControlImpl.getWSDLStream(
> 	at org.apache.beehive.controls.system.webservice.jaxrpc.ServiceControlImpl.initialize(
> 	at org.apache.beehive.controls.system.webservice.jaxrpc.ServiceControlImpl.invoke(
> 	at
> 	at
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(
> 	at 
> ----------------------------------------------------------------------------
> According to stack trace. In source code:
> 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
>, 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.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message