Re: Content is not allowed in prolog
Yuval wrote: Should I change something in my attachment or just in the client code? Do you know how to change the encoding of the request to utf-16? Yuval, I will just point you to this JIRA enhancement request I ran across a few weeks back, for changing the encoding for the SOAP message itself; I did test it with my 1.2.1 client, and it worked beautifully. http://issues.apache.org/jira/browse/AXIS-1682 I don't have any services using attachments, so I can't advise you, although I would expect you need to change that wherever you're creating the attachment... Since your code is working when you don't include an attachment, changing the encoding of the SOAP message probably isn't what you need. Has anyone else on the list encountered this? Meghan Pietila Granite Consulting
RE: Content is not allowed in prolog
On September 14, 2005, [EMAIL PROTECTED] wrote: >But when I'm running it under Tomcat 5.0 (The axis client is always running >from >the same place), I get the following exception: >org.xml.sax.SAXParseException: Content is not allowed in prolog Yuval, I don't have experience with the problem in Tomcat, but when I ran into this error before when sending SOAP xml to a Tibco BusinessWorks service, it was due to the UTF-8 BOM being prepended to the message. We temporarily got around it by switching to UTF-16, until we moved to a different technology that did not throw an exception. I believe it was related to this known JVM defect, although since we had a workaround I did not confirm the cause. If you can, try switching to a different type of encoding, that would help you narrow down whether UTF-8 is the issue. http://forum.java.sun.com/thread.jspa?threadID=623411&tstart=105 Good luck! Meghan Pietila Granite Consulting
Re: Field with second letter capitalized problem
Mike,
I didn't see any responses to your question about how to get Axis to map from
Java bean property names to the XML element names. I ran into what may be the
same problem a couple of weeks ago; from reading the Axis documentation, I
found that the generated classes should have type-mapping code inside them.
http://ws.apache.org/axis/java/user-guide.html#WSDL2JavaBuildingStubsSkeletonsAndDataTypesFromWSDL
In my case, it turned out that the type mapping code didn't exist because I had
IBM's WSAD installed on my machine, and its older WSDL2Java classes were
earlier in my classpath--I was generating very old code! Starting with a clean
classpath fixed that problem.
Hopefully this information helps you,
Meghan Pietila
Granite Consulting
--Begin message from Mike Pilone ([EMAIL PROTECTED]), 08/24/2005 09:21 PM
Hello all,
I am attempting to use Axis 1.2.1 to generate a client stub to the Systinet
UDDI registry. For most of the API I used the OASIS WSDLs and WSDL2Java. Aside
from some minor problems, it appeared to work.
However now that I am using the client stub, I am running into a problem. UDDI
defines the type tModel in the schema. There are many operations that return
tModels. For example, in a Taxonomy object, there is a tModel. What this means
is that Axis is generating a Taxonomy class that looks like:
Taxonomy
{
public void setTModel(
) {
}
public TModel getTModel() {
}
}
The problem comes when a response message comes back from the UDDI server in
which the tModel element is . The BeanDeserializer on the client side
is throwing an exception that the tModel element was unexpected. After stepping
through the code, I found that the tModel property in Taxonomy is getting
returned as TModel by bean introspection, therefore not matching the element
with name tModel. Looking at the JavaBeans spec, the introspection and
property name are correct.
Is there some way around this with Axis? It seems like a major problem, since
and field with a second capital letter will not match the XML elements defined
in the schema because of bean introspection. Note that this is the standard
UDDI WSDL. Im a bit worried that Axis cant properly talk to UDDI, one of the
leading technologies in web service registration and discovery.
Thanks for any help,
-mike
RE: changing the reponse character encoding
Rob, I ran across this JIRA issues a few days ago while looking into UTF-16 encoding. The discussion here may help answer your questions: http://issues.apache.org/jira/browse/AXIS-1682 The upshot is, it looks like the Axis service will respond in whatever encoding the client sends in. I am using a Siebel service, but setting this property did allow me to send from my client in UTF-16, using Axis 1.2.1. Meghan >From Robert Dietrick ([EMAIL PROTECTED]) on 08/18/2005 at 05:53 PM: >I want to force the character encoding of the response from *one* method >of my service to UTF-16, but I'm not having any luck finding out how to >do this. Can anyone provide a pointer? >Thanks. >-rob
RE: AW: Axis on IBM websphere5.0
Just to clarify-- We have not removed a "webservices.jar" file or made any modifications to our WebSphere install. You haven't described what problems you ran into; perhaps one of the circumstances of my setup is protecting us from the error--the fact that we don't use HTTP/HTTPS, or that we are not hosting any services but merely running clients, or the custom transport layer that I wrote and plugged in (to give us the JMS support we needed). I'm certainly not saying that the knowledge you have gained is not a good warning for others, but it appears that in some circumstances, Axis 1.2.1 can be used on WebSphere 5.1. Meghan Pietila Granite Consulting >>>Original messages below: >From [EMAIL PROTECTED] on 08/17/2005 at 01:24 PM CST: Yes, removing webservices.jar DOES work. HOWEVER! You CTO my skin you alive when the boat load of money you spent on WAS is lost as IBM will void all warrenty and support by deleting this jar. THUS, you might as well go with JBoss in that case... :-) Thank You Mick Knutson Sr. Java/J2EE Consultant BASE logic, inc. (415) 648-1804 (S.F., CA) http://www.BASELogic.com HP Consulting Services (Walnut Creek, CA) >From: [EMAIL PROTECTED] >Reply-To: axis-user@ws.apache.org >To: axis-user@ws.apache.org >Subject: RE: AW: Axis on IBM websphere5.0 >Date: Wed, 17 Aug 2005 16:29:45 + > >I, also am running Axis 1.2.1 on WebSphere 5.1. > >In my case, however, we're using a custom transport for JMS because the >existing one didn't support our needs--so if there are conflicts with the >HTTP/HTTPS handling, I wouldn't run into them. > >WSDL2Java generation worked great once I got the WSAD jars off my >classpath... (I was fooled for several days because I didn't realize I was >generating the old classes from the WSAD built-in WSDL2Java code). > >I am also running only as a client, and not a service, so it's possible >I've managed to avoid some problems that way. > >The marshalling/unmarshalling for rpc-encoded xml seems to be working >wonderfully, though, and that's the piece I really wanted Axis for, since >JAXB 1.5 cannot read the Siebel-generated WSDL I have, and can't handle >rpc-encoded services anyway (at least, from what I've been able to learn). >XMLBeans reads the WSDL, but also can't seem to handle the rpc-encoded >messages (at least, not without me hand-creating some schemas for the >message elements). > >Meghan Pietila >Granite Consulting
RE: AW: Axis on IBM websphere5.0
I, also am running Axis 1.2.1 on WebSphere 5.1. In my case, however, we're using a custom transport for JMS because the existing one didn't support our needs--so if there are conflicts with the HTTP/HTTPS handling, I wouldn't run into them. WSDL2Java generation worked great once I got the WSAD jars off my classpath... (I was fooled for several days because I didn't realize I was generating the old classes from the WSAD built-in WSDL2Java code). I am also running only as a client, and not a service, so it's possible I've managed to avoid some problems that way. The marshalling/unmarshalling for rpc-encoded xml seems to be working wonderfully, though, and that's the piece I really wanted Axis for, since JAXB 1.5 cannot read the Siebel-generated WSDL I have, and can't handle rpc-encoded services anyway (at least, from what I've been able to learn). XMLBeans reads the WSDL, but also can't seem to handle the rpc-encoded messages (at least, not without me hand-creating some schemas for the message elements). Meghan Pietila Granite Consulting
RE: Disable creation of "encoding="UTF-8"
I'll reply to my own message in case someone in the future needs this answer... I tracked the code snippet down to org.apache.axis.encoding.SerializationContext, in the writeXMLDeclaration() method. The method itself is fairly simple, and it's very obvious that there's no way to turn off the encoding bit of the XML declaration without turning off the whole declaration! I guess that's the end of the story there; I'll probably end up modifying the class in some way on my end as a workaround, so that I can work with the Siebel services until they figure out how to fix things (I was told that the .NET client also had to put in a workaround). FYI, I had the same problem when we started calling Tibco BusinessWorks services a few months back, but the Tibco developers stopped using the built-in SOAP processors and wrote their own, and that resolved the problem. I'm not sure what it is on the Siebel end, but on the Tibco end they have some code based in Java and I suspect they were running in to the JDK UTF-8 BOM issue (see link below). Changing the encoding to UTF-16 caused Tibco's black-box to work perfectly. http://forum.java.sun.com/thread.jspa?threadID=623411&tstart=105 Meghan Pietila Granite Consulting >I'll start searching the mail archives and JIRAs, but if anyone can short-cut >my >search by telling me this, I'd be grateful! Apparently, even though it >outputs xml >containing the encoding="UTF-8" text, the Siebel web service we are accessing >cannot stand receiving it. > >I think I remember that this came up a week or two ago, is there an easy way >to >tell Axis not to generate this in the xml header? > >Thanks much, > >Meghan
Disable creation of "encoding="UTF-8"
I'll start searching the mail archives and JIRAs, but if anyone can short-cut my search by telling me this, I'd be grateful! Apparently, even though it outputs xml containing the encoding="UTF-8" text, the Siebel web service we are accessing cannot stand receiving it. I think I remember that this came up a week or two ago, is there an easy way to tell Axis not to generate this in the xml header? Thanks much, Meghan
Re: encodingStyle attribute location
Ah. I hadn't backed up in the WS-I BP to see R1005, although I knew that WS-I didn't allow rpc/encoded and that should have told me right there. :) Well, unreasonable or not, they've already got a .NET client working on it and now they want my Java webapp to access the services, so I'll have to figure out something. I'll step through the Axis code a bit and see what I can learn about the possibilities for changing it... Meghan Pietila Granite Consulting On 8/10/05, [EMAIL PROTECTED] wrote: The folks from Seibel are smokin' something. The SOAP spec says: "The SOAP encodingStyle global attribute can be used to indicate the serialization rules used in a SOAP message. This attribute MAY appear on any element, and is scoped to that element's contents and all child elements not themselves containing such an attribute, much as an XML namespace declaration is scoped. There is no default encoding defined for a SOAP message." The WS-I BP says: "R1005 An ENVELOPE MUST NOT contain soap:encodingStyle attributes on any of the elements whose namespace name is "http://schemas.xmlsoap.org/soap/envelope/"."; Therefore the WS-I BP says that it must NOT be in the SOAP Body or SOAP Envelope elements. Of course, it also says: "R1006 An ENVELOPE MUST NOT contain soap:encodingStyle attributes on any element that is a child of soap:Body." RPC/encoded is always disallowed by WS-I BP. I suspect that Seibel's SOAP engine is just remarkably inadequate, so they're making unreasonable demands. Anne On 8/10/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I am using Axis 1.2.1, for rpc/encoded, as a Java client talking to a Siebel > SOAP service over JMS. > > Siebel insists that the encodingStyle attribute be in the soap Body or soap > Envelope elements. W3C SOAP standards state that the attribute can be in any > element in the message, but I did find that WS-I standards say it must be in > the soap Body (not that the rest of their service is WS-I compliant, but > vendors aren't always logical...) > > Axis is generating the encodingStyle attribute into the first element inside > the soap Body, which causes Siebel to reject the xml. > > I tried some JIRA and mailing list archive searches, and wasn't able to turn > up any discussions that seemed relevant. Is there a way to change this > behavior without modifying Axis code? > > Thanks, > > Meghan Pietila > Granite Consulting >
encodingStyle attribute location
I am using Axis 1.2.1, for rpc/encoded, as a Java client talking to a Siebel SOAP service over JMS. Siebel insists that the encodingStyle attribute be in the soap Body or soap Envelope elements. W3C SOAP standards state that the attribute can be in any element in the message, but I did find that WS-I standards say it must be in the soap Body (not that the rest of their service is WS-I compliant, but vendors aren't always logical...) Axis is generating the encodingStyle attribute into the first element inside the soap Body, which causes Siebel to reject the xml. I tried some JIRA and mailing list archive searches, and wasn't able to turn up any discussions that seemed relevant. Is there a way to change this behavior without modifying Axis code? Thanks, Meghan Pietila Granite Consulting
Re: stumped on deserializer problem
Sounds great, Thad! I'm currently stuggling with the custom (de)serialization-within-custom-(de)serialization problem, so I'll appreciate your writeup if I don't get it working first! Meghan Pietila Granite Consulting On Tuesday 08 August 2005 17:49, [EMAIL PROTECTED] wrote: >Bingo! I've cracked the custom (de)serialization for my classes. Moreover, >I've managed to figure out custom (de)serialization for a class when it >contains members that also require custom (de)serialization. >The later case was difficult because the exception I was getting in my >real-world problem didn't point to the source of the error. To solve this, I >created a simplified set of classes and (de)serializer. This pointed me >straight to the problem. I intend to write the axis-dev folks and offer a >write-up and my example for the user's manual.
RE: Exception in thread "main" java.lang.NoClassDefFoundError: org.apache.commons???
Don, The JAR file names in your classpath don't match up to the names in my 1.2.1 download of Axis; I had the same problem when I copied a classpath setup script from the wiki (but had forgotten until Tim mentioned it). You'll want to go through and compare each JAR name against the real JAR in your /lib directory; for example, commons-discovery.jar is actually commons-discovery-0.2.jar on my system. That might be all you need to do... we'll see if Tim comes up with something additional. If you haven't discovered this page on the wiki yet, it might be useful: http://wiki.apache.org/ws/FrontPage/Axis/UsingCommandLineTools BTW, thanks for the reminder about quotation marks for spaced-classpaths, Tim, I remember reading that once but had never needed to use it. :) Meghan Tim, This is what the AXISCLASSPATH look like, D:\axis121\AXIS-1~1\samples\stock>echo %AXISCLASSPATH% D:\axis121\axis-1_2_1\lib\axis.jar;D:\axis121\axis-1_2_1\lib\commons-dis covery.jar;D:\axis121\axis-1_2_1\lib\commons-logging.jar;D:\axis121\axis -1_2_1\lib\jaxrpc.jar;D:\axis121\axis-1_2_1\lib\saaj.jar;D:\axis121\axis -1_2_1\lib\log4j-1.2.8.jar;D:\axis121\axis-1_2_1\lib\xml-apis.jar;D:\axi s121\axis-1_2_1\lib\xercesImpl.jar Thanks, Don -Original Message- From: Bish, Tim [mailto:[EMAIL PROTECTED] Sent: Monday, August 08, 2005 10:15 AM To: 'axis-user@ws.apache.org' Subject: RE: Exception in thread "main" java.lang.NoClassDefFoundError: org.apache.commons??? What does you AXISCLASSPATH look like? Can you dump it out and attach paste it into an email? - Timothy A. Bish Sensis Corperation 5717 Enterprise Parkway East Syracuse, NY 13057 Phone: (315) 634-3027 [EMAIL PROTECTED] - -Original Message- From: Chen, Donald [mailto:[EMAIL PROTECTED] Sent: Monday, August 08, 2005 10:05 AM To: axis-user@ws.apache.org Subject: RE: Exception in thread "main" java.lang.NoClassDefFoundError: org.apache.commons??? Meghan, Thanks for the advice. I reran the commend and I got the same response: D:\axis121\AXIS-1~1\samples\stock>java -cp %AXISCLASSPATH% org.apache.axis.client.AdminClient -lhttp://localhost:8080/a is/services/AdminService deploy.wsdd Exception in thread "main" java.lang.NoClassDefFoundError: org.apache.commons.logging.LogFactory at org.apache.axis.components.logger.LogFactory.class$(LogFactory.java:45) at org.apache.axis.components.logger.LogFactory$1.run(LogFactory.java:45) at java.security.AccessController.doPrivileged(Native Method) at org.apache.axis.components.logger.LogFactory.getLogFactory(LogFactory.ja va:41) at org.apache.axis.components.logger.LogFactory.(LogFactory.java:33 ) at org.apache.axis.client.AdminClient.(AdminClient.java:48) Any idea? Don -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, August 05, 2005 5:19 PM To: axis-user@ws.apache.org Subject: Exception in thread "main" java.lang.NoClassDefFoundError: org.apache.commons??? Don, >From your copy and paste below, it appears that you put the AXISCLASSPATH variable in quotation marks. Don't do that; you want the shell to fill in the actual value--that's what the percent signs are for. Meghan Pietila Granite Consulting On a Win box, I followed the Axis 1.2 "Installation Guide" and tried the "Run the admin client" java -cp %AXISCLASSPATH% org.apache.axis.client.AdminClient -lhttp://localhost:8080/axis/services/AdminService deploy.wsdd I am pretty sure the path %AXISCLASSPATH% was set right, but I still got this errors: D:\axis121\AXIS-1~1\samples\stock>java -cp "%AXISCLASSPATH%" org.apache.axis. axis/services/AdminService deploy.wsdd Exception in thread "main" java.lang.NoClassDefFoundError: org.apache.commons at org.apache.axis.components.logger.LogFactory.class$(LogFactory.jav at org.apache.axis.components.logger.LogFactory$1.run(LogFactory.java at java.security.AccessController.doPrivileged(Native Method) at org.apache.axis.components.logger.LogFactory.getLogFactory(LogFact at org.apache.axis.components.logger.LogFactory.(LogFactory.j at org.apache.axis.client.AdminClient.(AdminClient.java:48) Is this related to the JCL classloader issue or something else? How can I go around it? This is my configure: Axis 1.2 Tomcat5.5.9, WinXPPro, JRE1.5. Thanks, Don
Exception in thread "main" java.lang.NoClassDefFoundError: org.apache.commons???
Don, >From your copy and paste below, it appears that you put the AXISCLASSPATH >variable in quotation marks. Don't do that; you want the shell to fill in the >actual value--that's what the percent signs are for. Meghan Pietila Granite Consulting On a Win box, I followed the Axis 1.2 Installation Guide and tried the Run the admin client java -cp %AXISCLASSPATH% org.apache.axis.client.AdminClient -lhttp://localhost:8080/axis/services/AdminService deploy.wsdd I am pretty sure the path %AXISCLASSPATH% was set right, but I still got this errors: D:\axis121\AXIS-1~1\samples\stock>java -cp "%AXISCLASSPATH%" org.apache.axis. axis/services/AdminService deploy.wsdd Exception in thread "main" java.lang.NoClassDefFoundError: org.apache.commons at org.apache.axis.components.logger.LogFactory.class$(LogFactory.jav at org.apache.axis.components.logger.LogFactory$1.run(LogFactory.java at java.security.AccessController.doPrivileged(Native Method) at org.apache.axis.components.logger.LogFactory.getLogFactory(LogFact at org.apache.axis.components.logger.LogFactory.(LogFactory.j at org.apache.axis.client.AdminClient.(AdminClient.java:48) Is this related to the JCL classloader issue or something else? How can I go around it? This is my configure: Axis 1.2 Tomcat5.5.9, WinXPPro, JRE1.5. Thanks, Don
RE: "Invalid element" error - Lower-case property name
All right, I've discovered that those classes I originally generated using WSDL2Java--with the missing meta-data--looked so odd because when I installed WebSphere Application Developer, it had WSDL2Java on the classpath. And it was earlier in the classpath than my Axis 1.2.1 jar. So I've been trying to get this stuff to work with code generated from something at least 2 years old... (no wonder there were IBM messages in the Javadoc! I thought the Axis team just hadn't cleaned the code up after IBM donated it...) So... for anyone else who has WSAD installed on their machine... now you know to be careful! If you're trying to generate code from WSDL with JMS endpoints, also be aware that you'll need to set the appropriate system property for the "jms" URL (i.e. -Djava.protocol.handler.pkgs="org.apache.axis.transport") I need to make some changes and then I can try running some different tests, hopefully this will clear up many of my errors. I noticed that quite a few of the Call properties are being set differently than in the "how to do JMS" pdf... Meghan Pietila Granite Consulting
RE: "Invalid element" error - Lower-case property name
I think I've made some progress; I found this archived mail: http://marc.theaimsgroup.com/?l=axis-user&m=102260719826152&w=2 It seems to indicate that when I ran WSDL2Java on the Siebel WSDL, some static code _should_ have been generated in my bean classes, to set up the XML -> Java mapping with an upper-case QName. (I ran a very basic WSDL2Java command; I just passed it the WSDL file name, and no options.) Re-reading the User Guide information on WSDL2Java again confirms this, now that I know what to look for. I don't have any idea yet why some expected things didn't generate, but since my number 1 non-standard piece is that I'm using JMS endpoints, my suspicions center there. I guess I'll start running some JIRA searches, then walk through the WSDL2Java code if nothing turns up in JIRA... if any of you out there have ideas, please let me know...! Meghan Pietila Granite Consulting
"Invalid element" error - Lower-case property name
I was encountering an "Invalid element" error when I attempted to receive a response message with my Axis client (Siebel service). I found this error mentioned many times in the axis-user mailing list archives, but was unable to find anyone listing an explanation or a solution. I debugged through the Axis code and noticed that the error was occurring because when BeanDeserializer.onStartChild is called, the "propertyMap" has "listOfUsbCustomerElement" as the child description, while the element is actually named "ListOfUsbCustomerElement". When I traced this back, I found that the lower-case name is coming from a call in the BeanDeserializerFactory that ends up retrieving the bean properties through introspection; hence, lower-case first letter in property names. As the archived email I reference below explains, one way around it is to customize the BeanInfo interface... I imagine Axis must somewhere normally provide a mapping to get from the Java name to the XML name... can anyone point me in the right direction? I suspect something is missing in my set up. In the meantime, I'll continue exploring... if I figure it out, I'll post the solution back here for anyone else who runs into this... Meghan Pietila Granite Consulting Archived mail referencing this problem: http://marc.theaimsgroup.com/?l=axis-user&m=103705794612785&w=2 Partial stacktrace illustrating the resulting error (Axis 1.2.1): 04-08-2005 15:16:36,688 [ERROR] org.apache.axis.client.Call: Exception: org.xml.sax.SAXException: Invalid element in com.blank.www.ListOfUsbCustomerOfferTopElmt - ListOfUsbCustomerOffer at org.apache.axis.encoding.ser.BeanDeserializer.onStartChild(BeanDeserializer.java:258) at org.apache.axis.encoding.DeserializationContext.startElement(DeserializationContext.java:1 035) at org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:165) at org.apache.axis.message.MessageElement.publishToHandler(MessageElement.java:1141) at org.apache.axis.message.RPCElement.deserialize(RPCElement.java:345) at org.apache.axis.message.RPCElement.getParams(RPCElement.java:384) at org.apache.axis.client.Call.invoke(Call.java:2448) at org.apache.axis.client.Call.invoke(Call.java:2347) at org.apache.axis.client.Call.invoke(Call.java:1804)
stumped on deserializer problem
Thad,
I didn't see any answers to your question, so I'll add what I know, having just
run into the same exception myself. When I went to add the typeMapping into my
.wsdd file, I found that adding the element qname didn't resolve anything--what
I needed to do, was add the _complexType_ qname.
My setup is a bit simpler, since I (think I) can just use the regular Axis
factories... I haven't managed to find much documentation on this stuff yet,
though, so I guess I'll find out by trial and error. I was able to get past
this error, however, and move on to a brand-new error (ah, change is
refreshing).
Example xml:
...
http://www.blank.com/xml/";
xsi:type="ns:ListOfBlankCustomerOfferTopElmt">
...
Matching .wsdd entry:
http://www.blank.com/xml/";
qname="ns:ListOfBlankCustomerOfferTopElmt"
type="java:com.siebel.www.ListOfBlankCustomerOfferTopElmt"
serializer="org.apache.axis.encoding.ser.BeanSerializerFactory"
deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
Meghan Pietila
Granite Consulting
Snippet from Thad's email:
I've been through the archives and seen numerous references to this same
problem. No suggestions have helped or clarified any of this for me.
(Judging from the frequency of this question, most other folks are stumped,
too.) Can someone clear this up? I promise to write this up for the Axis
docs if I ever getting it figured out. Maybe that will close this thread.
Recently I've read to start/restart Tomcat (I'm using TC 5.5.9) but that
hasn't worked. I'm using Axis 1.2.1.
I have a large set of Java classes that talk to a Sun RPC legacy application.
I want to access the legacy app via SOAP. The Java classes were written
without much (if any) thought to Beans (the Java API was to mimic the C/C++
API as closely as possible). Hence BeanSerialization is not appropriate
(methods like isFoo() or getFoo() often do not have an underlying foo
member). With the user's guide to custom serialization TBD, I have been
using samples/encoding and Google finds as a guide. When I adapt
samples/encoding/TestSer.java to test my class, it works perfectly but when I
try to call client-server via Axis, I get the exception:
"Caught RemoteException: org.xml.sax.SAXException: Deserializing parameter
'pObjectID': could not find deserializer for type
{urn:oasSoapNamespace}ObjectID"
Here (in summary) are my files classes:
// deploy.wsdd
http://xml.apache.org/axis/wsdd/";
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java";>
http://schemas.xmlsoap.org/soap/encoding/"/>
http://schemas.xmlsoap.org/soap/encoding/"/>
