Hi, Looks like the axis2.xml that your using has the JMS transport turned on. You can dissable it by commenting out the JMS transport (Section that starts with <transportReceiver name="jms" class="org.apache.axis2.transport.jms.JMSListener">) from the axis2.xml.
Thanks, Keith. On Thu, Oct 2, 2008 at 2:11 AM, Steve Cohen <[EMAIL PROTECTED]> wrote: > 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] > > -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org
