12-Oct-2005

Soap - once more
A double (triple?) size epsiode, since some updates have been missed)
(What happened before)
Compiling AXIS itself using ANT fails:

BPS2004A> @setup_ant DKA0:[AXIS.AXIS-1_1.openvms.libjars]
BPS2004A> set def DKA0:[AXIS.AXIS-1_1]
BPS2004A> ant
Buildfile: build.xml
setenv:
check-javadoc-needed:
printEnv:
...
compile:

BUILD FAILED

file:/dka0/axis/axis-1_1/build.xml:91: Could not create task or type of type: depend.

Ant could not find the task or a class this task relies upon.

This is common and has a number of causes; the usual solutions are to read the manual pages then download andinstall needed JAR files, or fix the build file:
- You have misspelt 'depend'.
Fix: check your spelling.
No, is Ok
- The task needs an external JAR file to execute
and this is not found at the right place in the classpath.
Fix: check the documentation for dependencies.
Nothing in there...
Fix: declare the task.
??? What is that?
- The task is an Ant optional task and optional.jar is absent
Fix: look for optional.jar in ANT_HOME/lib, download if needed
Exists, but something might be missing in there??
- The task was not built into optional.jar as dependent libraries
were not found at build time.
Fix: look in the JAR to verify, then rebuild with the needed
libraries, or download a release version from apache.org
That might be the case, but I consider this a deliverable, so it SHOULD already be in there...
- The build file was written for a later version of Ant
Fix: upgrade to at least the latest release version of Ant
1.5 is good, isn't it?
- The task is not an Ant core or optional task
and needs to be declared using . Using what?
...
Total time: 8 seconds

I removed the DEPEND line, but that did not really help (edited lines to fit on screen):

[javac] /dka0/axis/axis-1_1/src/org/apache/axis
/encoding/ser/MimeMultipartDataHandlerDeserializer.java:65:
package javax.mail.internet does not exist
[javac] import javax.mail.internet.MimeMultipart;
[javac] ^
[javac] /dka0/axis/axis-1_1/src/org/apache/axis
/encoding/ser/MimeMultipartDataHandlerSerializer.java:65:
package javax.mail.internet does not exist
[javac] import javax.mail.internet.MimeMultipart;
[javac] ^
[javac] /dka0/axis/axis-1_1/src/org/apache/axis
/handlers/EchoHandler.java:58:
warning: java.io.StringBufferInputStream in java.io has been deprecated
[javac] import java.io.StringBufferInputStream;
[javac] ^
[javac] /dka0/axis/axis-1_1/src/org/apache/axis
/handlers/EchoHandler.java:59: package javax.servlet.http does not exist
[javac] import javax.servlet.http.HttpServletRequest;
[javac] ^
[javac] /dka0/axis/axis-1_1/src/org/apache/axis
/holders/MimeMultipartHolder.java:57:
package javax.mail.internet does not exist
[javac] import javax.mail.internet.MimeMultipart;

Left this to Brad to solve. It might be a problem when building the webservices thenselves.
Try it all using a test program, and build that to see whether the method itself will work.
(Today's episode)
I tried to include the xstream package but compiling failed, because the package could not be found:

BPS2004A> javac "ExecTest.java"
ExecTest.java:3: package
com.thoughtworks.xstream does not exist
^
met als gevolg dat alle
referenties fout gaan:
ExecTest.java:36: cannot resolve symbol
symbol :
class XStream
location: class ExecTest
^
ExecTest.java:36: cannot
resolve symbol
symbol : class XStream
location: class
ExecTest
^
ExecTest.java:74: cannot resolve symbol
symbol : variable
xstream
location: class ExecTest
^
ExecTest.java:98: cannot resolve
symbol
symbol : variable length
location: class
ExecTest.Args
^
ExecTest.java:100: cannot resolve symbol
symbol :
variable arg
location: class ExecTest

Stupidly enough, the package is IN the path.
As a last resort, unpacked the package:

jar -xvf xstream112.jar

and the result (com.thoughtworks.xstream) came in a completely unexpected directory. Next copied the files to the base location (aside the source directory) and all of a sudden: COMPILATION SUCCEEDED.
It seems that the java compiler has a problem with the number of entries in logical JAVA$CLASSPATH ???

Running was another problem, it proved to need another package - even the older version (1.0.2, I used 1.1.2 to start with). The same applied here: when a package is included in a .JAR file, the java compiler, nor the runtime did read it.
(I checkd the file format: RFM:STREAM_LF was missing but setting this didn't change it. However, jar had no problems with it).
Once that was solved, and a few other things had been changed, the test process did work:

BPS2004A> java "ExecTest" "Grooters" "Willem" "19520212"
Param
0:Grooters
Param 1:Willem
Param 2:19520212
Executing string:
test_ws:[000000]display_args.com Grooters Willem 19520212
### Following lines
came back from SYS$ERROR:
### Following lines came back from
SYS$OUTPUT:
Achternaam=Grooters
Achternaam=Willem
Achternaam=19520212
***
End of ExecTest ***
BPS2004A>

The thing found, to be reckoned with (and which is AGAINST the standard (I think): The XML that is written in the native application MUST have exactly the same case as the field- and class specification it is translated to!

And by the way: the com.microsoft.wsdl/types problem has been soved as well. I guess it was in some package that was expanded, but the required classes are found.
(Next epsiode preview)
Since the webservices use arrays of classes, the example program will have to be rewritten ot faciliate that. There has already been done some in that but there is a problem with xstream.fromXML complaining on something "empty". That should be solved first, and after that, the webservices are to be done. But first, need to report....
(will be continued)
Updates to WindowsXP
Loaded and installed a bunch of security updates to Windows, on Athene and Aphrodite. No time to do this on Hera (yet).
Of course updates Virus scanner andadware/malware/spyware removers.
No breaches in the last days - just a number of spammers to track.