The light dawns on this dinosaur's brain. Slowly, slowly. But it dawns.
I think I am not supposed to use in my client code (or even look at :-))
these wretched classes that WSDL2Java created. Leave these classes for
the audience they were designed for, that is, for axis itself. Instead,
in my client code, use the OMElement methods as in the sample, to build
my data elements from element names defined in the WSDL.
That produces a readable xml fragment. This is odd to me but workable.
However, I am still not out of the woods yet. Though it produces a
viable Soap Body, my SoapHeader was not being produced. This is because
the configuration process is not quite so simple as described. This line
ConfigurationContext ctx =
ConfigurationContextFactory.createConfigurationContextFromFileSystem(args[1],
args[1] + "/conf/axis2.xml");
is failing for me, even when I modify the parameters to fit my system,
because of this error:
Exception in thread "main"
org.apache.axis2.deployment.DeploymentException: javax/jms/BytesMessage
at
org.apache.axis2.deployment.AxisConfigBuilder.processTransportSenders(AxisConfigBuilder.java:663)
at
org.apache.axis2.deployment.AxisConfigBuilder.populateConfig(AxisConfigBuilder.java:119)
at
org.apache.axis2.deployment.DeploymentEngine.populateAxisConfiguration(DeploymentEngine.java:641)
at
org.apache.axis2.deployment.FileSystemConfigurator.getAxisConfiguration(FileSystemConfigurator.java:116)
at
org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContext(ConfigurationContextFactory.java:68)
at
org.apache.axis2.context.ConfigurationContextFactory.createConfigurationContextFromFileSystem(ConfigurationContextFactory.java:184)
...
Caused by: java.lang.NoClassDefFoundError: javax/jms/BytesMessage
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357)
at java.lang.Class.getConstructor0(Class.java:2671)
at java.lang.Class.newInstance0(Class.java:321)
at java.lang.Class.newInstance(Class.java:303)
at
org.apache.axis2.deployment.AxisConfigBuilder.processTransportSenders(AxisConfigBuilder.java:648)
... 6 more
This is a little surprising - Axis is expecting a JMS support library to
be loaded on the runtime classpath? Perhaps a valid assumption in an
application container - but how about a standalone client? What jar
must I place on my runtime classpath to resolve this dependency?
Steve Cohen wrote:
Thanks again, Mary.
However, I am still in no-joy land. This is because of the absolutely
wretched code that WSDL2Java generated for me from this WSDL. (See
http://marc.info/?l=axis-user&m=122279472601179&w=2) or
to recapitulate that thread, I got the WSDL here
https://duoshare.com/dsWS/services/PostML/wsdl
and processed it with Java2WSDL using these options
-o {root of my source tree} -t -d adb -u -ssi -wv 1.1 -or
-Ejavaversion 1.5 -uri {my wsdl}
which created a mess of compilable but ungodly code. Therefore what
should be simple setters and getters are instead gnarly thickets of
BlahBlahBlah_type1 each of which in turn has a setter for
BlahBlahBlah_type0, all to stick a stinking string parameter into an
XML packet.
Therefore I am unable to do the simple kinds of things in sample03 and
must instead learn this whole axiom object model in order to work with
this code.
Or something. I don't know what.
I think I need a WSDL2Java expert to tell me how to generate better
code from this WSDL.
Mary Thompson wrote:
Steve,
axis2.xml will be read by the appropriate library method if it
appears on your class path, or is specified using a
-Daxis2.xml=<pathname> Java option when you run the client, or set by
a System.setProperty("axis2.xml",<pathname> ) call in your program.
In my experience, the pathname needed to be relative to the classpath.
The axis2.xml sections for rampart are the <module ref="rampart">
line and the OutflowSecurity and InflowSecurity sections, specifying
the security properties of the request and response messages.
I think that samples/basic/sample03/client-axis.xml would give you
want you want for the security heading. Since the message is not
signed you don't need the properties or keystore files.
I'm not sure how you would set the user interactively. You can
probably write a PWCBHandler that prompts for a username and
password, and then add them to the header.
As for the addressing part of the message I would guess that the
addressing module handles that, but I have no experience with it.
Hope this is a bit of help
Mary
Steve Cohen wrote:
Okay, thanks Mary.
On your suggestion and others I have rethought and begun switching
to Axis2 so that I might use Rampart. I am looking at the samples
and they pose a question I want to understand.
That is, the use of client.axis2.xml as in the samples.
WSDL2java did not generate this file for me and I'm not sure what is
going to cause this file to be read.
Can you explain how this works? Once I get past this, I think I
will be on my way.
Thanks.
Steve
Mary Thompson wrote:
If you mean axis2 1.4, the Rampart module will do that for you. The
Axis pages link to some documentation and to the rampart 1.3
module. Go to
http://ws.apache.org/rampart/download/1.4/download.cgi for rampart
1.4 and more documentation.
After you have read the overviews, look at the rampart/samples
code. I think samples/basic/sample03 may do what you want.
Mary
Steve Cohen wrote:
I am trying to generate java Client code to access a web service
from a WSDL using axis 1.4. Documentation that comes with the
WSDL expects me to generate packets with SOAP headers that look
something like this.
q
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
