On further investigation, I find that client.03 fails in the sample with
the same error (java.lang.NoClassDefFoundError:
javax/jms/BytesMessage). Before I got to that point, I also had to
modify the build.xml file in the samples/basic directory changing
<property name="addressing.mar" value="addressing-1.1.mar"/>
to
<property name="addressing.mar" value="addressing-1.4.mar"/>
since that is what was installed with axis2-1.4.
Is rampart written for axis2-1.3 rather than 1.4 and would I possibly be
better off using that platform?
Steve Cohen wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
