-- EduardoPelegri - 17 Nov 2004

A: this seems to happen with some JDK1.5/JWSDP1.5 installations. If the installer does not automatically recognize your JDK(s) try one of the following workarounds:

• 1- launch the JWSDP installer by command-line specifying the switch -is:javahome <JAVA_HOME>
• 2- if you have only one JDK 1.5 installed, then remove it, install an older JDK 1.4.X, then install also the JDK 1.5; when the installer will prompt which JDK to use, choose JDK 1.5. If the JDK you wish is not shown, use the "browse" button to manually select it.
• 3- try to download the latest JWSDP build

Q: JWSDP1.5 installer hangs without errors and the installation never ends, what can I do?

A: there's not an exact diagnosis for this issue, anyway you can try these steps:

• download the "very" latest build available of the JWSDP and try again
• try to run the installer from a remote shell (only unix)
• check if all the mount points are currently available (i.e. NFS file systems), since the installaer checks them and could hang here if one of them is not reachable. If they are not, unmount them
• try to run the installer using the silent mode (i.e. "jwsdp-1_5-unix.sh -P installLocation="/var/jwsdp-1.5" -silent")
• if you want to know what the installer is doing before hanging, you could try to truss the installer process (i.e. "truss -eafl -wall -vall -rall -o truss.out -p <INSTALLER_PID>") under Solaris, or by using the equivalent "strace" command under Linux
• as always, try also to download the latest JWSDP build

Q: the sample jaxr-browser return errors ("Unable to internalize message") when connecting to sample JAXR registry server, what can I do?

A: The checklist in this case is:

• check that the webapps RegistryServer^? and Xindice are correctly deployed and running in the webserver you are connecting to.

• check the log(s) of the webserver, it should not contain any exception related to the previous webapps
• if you are using Java 1.5 and you also have a Java 1.4.x installation, then try to change JAVA_HOME in JWSDP_HOME/jwsdp-shared/bin/setenv.sh(.bat) to point to JDK 1.4.2X home.

Q: I have a WSDL which defines a part in the soap:header of the input message, but wscompile generates a stub having an operation without this parameter, why?

A: you need to specify the -f:explicitcontext option in the wscompile command-line

Q: I have a WSDL which defines a part in the soap:header of the output message, but wscompile generates a tie which can't be compiled because the automatically generated java source class contains an undeclared variable ("_headerObj"), is this a bug?

A: Yes, actually It's a known bug (#6211505 ) A possible workaround is to manually edit the _Tie class and add a declaration for that variable (its type is "Object"), then compile it by hand. Another workaround could be to modify the WSDL and move that part from the header to the body, then implement an handler which moves this part from the body to the header.

Q: can I write a webservice without using a package?

A: Nope, it seems it's not actually possible

Q: when I run wscompile with multiple comma-separated features values (-f switch) I get "file not found", why?

A: a multiple features list after the -f (or -features) option must be specified within quotes, i.e.:

wscompile -gen:server -f:"explicitcontext,wsi,searchschema" config.xml

you can also split it into:

wscompile -gen:server -f:explicitcontext -f:wsi -f:searchschema config.xml

Q: can I install the newer JWSDP1.5 on the older "tomcat-jwsdp1.4" webcontainer given with JWSDP1.4?

A: Yes you can

Q: wscompile fails saying "modeler error: uniqueness constraint violation", what's the reason?

A: this could be due to some parameter name clash (same names for different elements in the same wsdl), or to some multi-value parameter which is not allowed... double-check carefully your WSDL and try to debug it by commenting "suspicious" blocks (and good luck!)

A: in some particular cases, wscompile could raise the "uniqueness constraint violation" even if you do NOT have any element with same name: in this case, you could try to pass the "-f:wsi" flag to the wscompile and the error should disappear.

Q: what's the release date of the next JWSDP?

A: N/A

Q: which components of the JWSDP 1.5 are/aren't redistributable?

A: take a look at: http://java.sun.com/webservices/docs/1.5/ReleaseNotes.html

Q: does xws-security of JWSDP support AES data encryption algorithm?

Q: what encryption algorithms are supported in jwsdp 1.4-1.5? only 3DES?

A: actually triple-des is the only data encryption algorithm supported in jwsdp 1.4-1.5. But the next release will definitely provide support for AES.

Q: what's the difference between xws-security EA and xws-security FCS?

Q: my annotators/filters-based wss classes doesn't work anymore in JWSDP1.5, why?

A: xws-security EA was a preliminary version of the web services security framework included in JWSDP 1.4, it became final (FCS) in JWSDP 1.5. The main difference is that the programmatic use of the security APIs (i.e. security filters) is not anymore supported: the framework is now less procedural and more declarative. You can feed some xml security descriptors to wscompile to implement the needed security layer. For further information see samples in JWSDP15_HOME/xws-security/samples.

Q: I've many problems implementing a web services security layer using filters in JWSDP 1.4, where can I find help?

A: read previous FAQ and evaluate carefully the opportunity to switch to JWSDP 1.5

Q: does JWSDP use JSR105 and JSR106?

A: JSR105 (XML Digital Signature) is supported (EA version) but not used in the xws-security framework (which uses instead a wrapper to the Apache XML Security APIs); this is valid both for JWSDP 1.4 and 1.5. An implementation of JSR105 anyway can be found in JWSDP_HOME/xmldsig/samples. Future releases of JWSDP will probably use JSR105 and JSR106 (XML Encryption) in the xws-security framework too.

Q: can I run my webservices on HTTPS? What do I need to do?

A: yes you can. Nothing more should be needed than changing the endpoint url address from http to https. Of course, on the client side, the jax-rpc client must be aware of the ssl-related jvm system properties (javax.net.ssl.trustStore, javax.net.ssl.trustStorePassword, javax.net.ssl.trustStoreType, javax.net.ssl.keyStore, javax.net.ssl.keyStorePassword, javax.net.ssl.keyStoreType, java.protocol.handler.pkgs, ...) : this can be achieved both by setting them programmatically inside the client code or at command-line level in the jvm startup script. For further information: http://java.sun.com/products/jsse/install.html . On the server side, you must configure the HTTPS listener, which is different for each kind of web/application server; for tomcat you can find further information here: http://java.sun.com/webservices/docs/1.0/tutorial/doc/WebAppSecurity6.html

Q: what types can a web service return?

Q: what types can I pass to a web service call?

A: Supported types are listed here: http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JAXRPC4.html

Q: does wscompile or wsdeploy automatically create the web.xml for the war file?

A: Nope, the web.xml file must be created by hand. It's just a standard web-app descriptor file without any "special" parameter; usually, for a simple webservice war file, a web.xml file like the following one is enough:

<?xml version="1.0" encoding="UTF-8"?>

<web-app>

<display-name>My webapp</display-name>

<description>my JAX-RPC based webapp</description>

</web-app>

this web.xml will be included in the raw war. Later the wsdeploy processes it to generate a new web.xml with some additional parameters needed by JAX-RPC and renames the old web.xml to web-before.xml: both are then included in the cooked war.

Q: I get a StackOverflowError^? trying to run wscompile on my wsdl / on Amazon wsdl / on a wsdl with cyclic references using "ref" attributes, why?

A this is a konwn bug (https://jax-rpc.dev.java.net/issues/show_bug.cgi?id=9) and it has been already fixed, try to use the latest JWSDP build.

-- Alessio Cervellin - Main.alessioc - 15 Feb 2005