I've inherited a rather crufty installation of the the Sun Application
Server, used to provide a bunch of SOAP services. This is not an
up-to-date version of the Application Server. In fact, it is the version
that is on the CD that comes with the J2EE tutorial book from Sun. I'm not
sure of the exact version number, but it is the one whose download file is
named "j2eesdk-1_4-linux.bin".
As part of the build procedure for these SOAP services, this
command is executed:
wsdeploy -o out.war in.war
and it works fine. If I try to build these SOAP services on a system with a
later version of the Application Server installed (I've tried the ones whose
download files are "j2eesdk-1_4_02_2005Q2-linux.bin" and
"j2eesdk-1_4_03-linux.bin"), the wsdeploy command fails, with this error:
======================
error: org.w3c.dom.DOMException: NOT_FOUND_ERR: An attempt is made to reference a node in a context where it does not exist.
org.w3c.dom.DOMException: NOT_FOUND_ERR: An attempt is made to reference a node in a context where it does not exist.
at com.sun.org.apache.xerces.internal.dom.ParentNode.internalInsertBefore(ParentNode.java:398)
at com.sun.org.apache.xerces.internal.dom.ParentNode.insertBefore(ParentNode.java:321)
at com.sun.xml.rpc.tools.wsdeploy.DeployTool.defineServletsAndListeners(DeployTool.java:437)
at com.sun.xml.rpc.tools.wsdeploy.DeployTool.run(DeployTool.java:258)
at com.sun.xml.rpc.util.ToolBase.run(ToolBase.java:43)
at com.sun.xml.rpc.tools.wsdeploy.Main.main(Main.java:22
======================
I can strip down in.war to almost nothing, and this still happens, so it
doesn't seem to be a problem with the code itself in the SOAP services
implementation doing something bad. With this simple in.war:
Length Date Time Name
-------- ---- ---- ----
0 07-29-06 11:38 META-INF/
107 07-29-06 10:24 META-INF/MANIFEST.MF
0 07-29-06 16:36 WEB-INF/
0 07-29-06 11:44 WEB-INF/lib/
680 07-29-06 16:36 WEB-INF/jaxrpc-ri.xml
1639 07-29-06 10:24 WEB-INF/sun-web.xml
2655 07-29-06 10:24 WEB-INF/web.xml
0 07-29-06 10:24 WEB-INF/classes/
0 07-29-06 16:23 WEB-INF/classes/org/
0 07-29-06 16:36 WEB-INF/classes/org/example/
0 07-29-06 16:36 WEB-INF/classes/org/example/malware/
183 07-29-06 16:36 WEB-INF/classes/org/example/malware/foo.class
533 07-29-06 16:36 WEB-INF/classes/org/example/malware/fooImpl.class
where foo provides a single SOAP call, which is an empty function, I still
get the error. It doesn't matter if I'm building with asant, or just doing
the wsdeploy command by hand. ("/opt/SUNWappserver/bin/wsdeploy -o out.war
in.war"). It's not a matter of something missing in my underlying Java
environment, because I have a system where I've got all three versions of
the appserver installed, in /opt/SUNWappserver, /opt/SUNWappserver2, and
/opt/SUNWappserver3, and one works and the other two fail. (The order I
installed those was the 1_4_02 version, then the 1_4 version, then the
1_4_03 version, so it is the one that was installed in the middle that
works, eliminating the possibility that the multiple versions interfere with
each other and only the first or last works).
Here's the specific version information for the different wsdeploys:
The one that works:
JAX-RPC Standard Implementation (1.1.1, build R5)
The ones that get the error:
JAX-RPC Standard Implementation (1.1.2_04, build R45)
JAX-RPC Standard Implementation (1.1.3, build R1)
I tried building the SOAP service from the J2EE Tutorial book's CD, and that
works fine on these later versions--but it doesn't use wsdeploy in the build
procedure. (Like I said, I inherited this thing...I'm not really up on the
details of the server side of J2EE yet, so don't understand yet why some
SOAP services would be built using wsdeploy and some would not).
(Oh, I also tried the -source option to wsdeploy, specifying all the
allowed versions, to see if that had anything to do with it. It doesn't).
Anyone have any ideas as to what the heck is wrong?

Signature
--Tim Smith
Tim Smith - 31 Jul 2006 19:11 GMT
> Anyone have any ideas as to what the heck is wrong?
OK, with a bunch of experimenting, I've figured it out. In the web.xml file,
if any of the resource-ref elements have a description element in them,
wsdeploy fails.
Since description is an optional element, I can work around this by getting
rid of them.

Signature
--Tim Smith