Re: null handling in apache soap2.2
John, I ran into the same problem. In my case, there was a conflict in the webcontainer.jar file from IBM. I don't know what the conflict was, but moving the Apache SOAP jar file above webcontainer.jar in my runtime classpath solved the problem. It sounds like you have a similar conflict. Try creating a very simple client and server with just the SOAP and Xerces jar files. If that test works just keep adding jar files back in until you find the culprit. Shawn. john@sixthdimens To: [EMAIL PROTECTED] ion.com cc: Subject: null handling in apache soap2.2 04/04/2002 05:26 PM Please respond to soap-user Hi I'm implementing an apache SOAP client that interacts with a WebLogic 6.1 sp2 based SOAP server application. The server has a method that's supposed to return a null object. For example, Person getPerson(String id) and if this 'id' is bogus, this method returns a null object. Note that the Person class is a standard JavaBean. Now, when I actually invoke this method on the weblogic hosted service with a bogus id, I get the following XML fragment as the SOAP response: I was assuming that the SOAP deserializer would convert this into a 'null' object. Instead, within my apache based client, I get a Person object that has null fields within. btw, I'm using Apache SOAP 2.2 on the client side, with the standard BeanSerializer/BeanDeserializer used to marshall/unmarshall the .java classes thanx -john This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates.
[SOLVED]: Re: Service's exception text not serialized???
I've found that the exception message string is not XML encoded. However
it is XML decoded in the client!?!?! This sounds like a bug to me...
Anyway, change
throw new Exception("");
to
throw new Exception(org.apache.soap.Utils.cleanString(""));
and all is well.
You don't have to XML decode in the client because it's already done!!
Shawn.
hughes_shawn@jpm To: [EMAIL PROTECTED]
organ.comcc:
Subject: Service's exception text not
serialized???
03/20/2002 02:03
PM
Please respond
to soap-user
My SOAP (2.2) service includes the stack trace when throwing the exception.
However the exception message is not serialized. It is easily
reproducible, just throw an exception that contains unescaped XML
characters, e.g.
public String getPublication(PublicationInputModel inputModel) throws
Exception {
throw new Exception( "" );
}
The only obvious solution is to encode the string and decode it in the
client. Has anyone else run into this problem?
Shawn.
This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.
Re: DeployedServices.ds
In web.xml (registration of the rpcrouter servlet): rpcrouter Apache-SOAP RPC Router org.apache.soap.server.http.RPCRouterServlet ConfigFile WEB-INF/soap.xml In WEB-INF/soap.xml (define the config manager, locate the SOAP deployment descriptor file): In WEB-INF/dds.xml (SOAP deployment descriptor): http://xml.apache.org/xml-soap/deployment"; id ="urn://ibportal.jpmc.com/ChartService" checkMustUnderstands="false"> http://schemas.xmlsoap.org/soap/encoding/"; xmlns:x ="http://www.chartservice.com/schemas/ChartServiceRemoteInterface"; qname ="x:com.jpmc.ibportal.integration.model.ChartDataInputModel" javaType ="com.jpmc.ibportal.integration.model.ChartDataInputModel" xml2JavaClassName ="com.jpmc.ibportal.integration.soap.encoding.soapenc.ForgivingBeanSerializer" java2XMLClassName ="com.jpmc.ibportal.integration.soap.encoding.soapenc.ForgivingBeanSerializer"/> http://schemas.xmlsoap.org/soap/encoding/"; xmlns:x ="http://www.chartservice.com/schemas/ChartServiceRemoteInterface"; qname ="x:com.jpmc.ibportal.integration.model.ChartListInputModel" javaType ="com.jpmc.ibportal.integration.model.ChartListInputModel" xml2JavaClassName ="com.jpmc.ibportal.integration.soap.encoding.soapenc.ForgivingBeanSerializer" java2XMLClassName ="com.jpmc.ibportal.integration.soap.encoding.soapenc.ForgivingBeanSerializer"/> ...More services ... Everything listed is deployed in my webapp. I deploy using my own war file (ifservice.war). I suspect is would make no difference if the war was contained in an ear file but have not tried it. Shawn. [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: 03/20/2002 01:37 Subject: Re: DeployedServices.ds PM Please respond to soap-user Would placing this inside a .ear file affect the way that this "should" work? > I have something similiar to that. Do these files live in the soap.war file? One > other question, what do you have in the > dds.xml file? > > Thanks, > Dave > > [EMAIL PROTECTED] wrote: > > > I use an XML configuration file (not the .ds file) so this may or may not > > work. Anyway, you can change the config file location in web.xml using the > > RPC router init parameter "ConfigFile", e.g. > > > > web.xml: > > > > rpcrouter > > Apache-SOAP RPC Router > > org.apache.soap.server.http.RPCRouterServlet > servlet-class> > > > > faultListener > > org.apache.soap.server.DOMFaultListener > param-value> > > > > > > ConfigFile > > WEB-INF/soap.xml > > > > > > > > Then I define the location of the deployment descriptor file (dds.xml). > > > > soap.xml: > > > > > > > > > > > > > > There is probably a similar configuration setup using the .ds file. > > > > Shawn. > > > > > > > > [EMAIL PROTECTED] To: [EMAIL PROTECTED] > >cc: > > 03/20/2002 11:06 Subject: DeployedServices.ds > > AM > > Please respond > > to soap-user > > > > > > > > Has anyone succesfully been able to specify a different location for the > > DeployedServices.ds file. I have tried a few times and it always seems > > like the servlet never picks up any
Service's exception text not serialized???
My SOAP (2.2) service includes the stack trace when throwing the exception.
However the exception message is not serialized. It is easily
reproducible, just throw an exception that contains unescaped XML
characters, e.g.
public String getPublication(PublicationInputModel inputModel) throws
Exception {
throw new Exception( "" );
}
The only obvious solution is to encode the string and decode it in the
client. Has anyone else run into this problem?
Shawn.
This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.
Re: DeployedServices.ds
I use an XML configuration file (not the .ds file) so this may or may not work. Anyway, you can change the config file location in web.xml using the RPC router init parameter "ConfigFile", e.g. web.xml: rpcrouter Apache-SOAP RPC Router org.apache.soap.server.http.RPCRouterServlet faultListener org.apache.soap.server.DOMFaultListener ConfigFile WEB-INF/soap.xml Then I define the location of the deployment descriptor file (dds.xml). soap.xml: There is probably a similar configuration setup using the .ds file. Shawn. [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: 03/20/2002 11:06 Subject: DeployedServices.ds AM Please respond to soap-user Has anyone succesfully been able to specify a different location for the DeployedServices.ds file. I have tried a few times and it always seems like the servlet never picks up any of the changes that I make to the deployment descriptor. If anyone as any suggestions I would appreciate it. Thanks, Dave Hirst This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates.
Re: Change management of web service input/output models???
For posterity I'll post my solution :-)
I solved this by creating a custom BeanSerializer. I just used the Apache
BeanSerializer and ignored the exception thrown by the getWriteMethod in
the unmarshall method:
try {
propWriteMethod = getWriteMethod(param.getName(), properties,
javaType);
} catch (IllegalArgumentException iae) {
System.out.println("Warning, IllegalArgumentException thrown, but
continuing");
System.out.println( iae );
}
I only did this on the web service side (in my case I don't forsee the
service upgrading before the client, the service will always be behind).
So I created the new class in a new package
(com.jpmc.ibportal.integration.soap.encoding.soapenc.ForgivingBeanSerializer)
and modified the DeploymentDescriptor.xml to reflect the serializer to use
for my beans, e.g.
I only changed the serializer for the deserializer (xml2JavaClassName).
GLUE was recommended but at this stage I did not want to make a drastic
change...
Shawn.
hughes_shawn@jpm To: [EMAIL PROTECTED]
organ.comcc:
Subject: Change management of web
service input/output models???
03/11/2002 04:48
PM
Please respond
to soap-user
What is the best way to deal with changes in the input and/or output model
of a web service?
Any references to general change management solutions are appreciated.
In my case, there are n different groups implementing a SOAP service. If a
new field is added to the input model all groups must simultaneously
upgrade the input model definition (otherwise deserialization will fail
once the model is changed in the client). Generally, however, the change
will simply be the addition of a new field, not modifying or removing an
existing field. Given this, a good solution is to allow legacy services to
simply ignore the new field. This will allow the interested service
implementor to recognize the new field while the other groups ignore it
until they are ready to upgrade the input model.
One solution is to subclass or create my own BeanSerializer which drops a
field it doesn't recognize during deserialization (currently the Apache
BeanSerializer will fail). I thought this was a good idea until I tried to
find someone else who has done the same thing. I couldn't, which makes me
think this may not be a good idea.
Another is to flatten the input model to a Map such that all input models
are just name/value pairs. I don't like this because the input model must
be flattened.
Lastly, I could add a new service accepting the new input model. This
would require UDDI wrapper code in the client to direct the request to the
appropriate version of the service.
Any experiences or suggestions welcome.
Thanks,
Shawn.
This communication is for informational purposes only. It is not intended
as
an offer or solicitation for the purchase or sale of any financial
instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made
herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.
This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or st
Re: HELP : xsi:null="true"
I ran into a problem using Apache SOAP 2.2 within WSAD (WebSphere Studio Application Developer IDE). To solve it the Apache SOAP jar had to appear before WSAD's webcontainer.jar in the CLASSPATH. There was a method conflict that caused the null objects to deserialize to objects built with the default constructor. You may have a similar conflict in one of your jar files. Shawn. [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: 03/13/2002 10:53 Subject: Re: HELP : xsi:null="true" AM Please respond to soap-user On Wednesday 13 March 2002 12:05, you wrote: > Its xsi:nil and not xsi:null for specifying that an element value holds a > null value... dovle pretty sad to disappoint you but this is the answer that I am reveiving from my apache soap when an attribute has null value: (snapshot from UtilSnoop) http://xml.apache.org/xml-soap"; xsi:type="ns3:Vector" xsi:null="true"/> 0 http://schemas.xmlsoap.org/soap/encoding/"; xsi:type="ns4:Array" ns4:arrayType="xsd:boolean[]" xsi:null="true"/> Are you shure that you receive the xsi:nil="true" ? I have read the Soap specification and I have found the same : A NULL value or a default value MAY be represented by omission of the accessor element. A NULL value MAY also be indicated by an accessor element containing the attribute xsi:null with value '1' or possibly other application-dependent attributes and values. (Quoting from W3C specs for ksoap1.1) So what could be wrong inhere ? Has anyone managed to send an struct object with null attribute values ? (I believe you have but ...) TIA for your answers dovle This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates.
Re: Problems on WAS
Here the link to the WAS-Apache SOAP 2.2 Installation Instructions for WAS... http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-soap/java/docs/install/websphere.html This is an XML parser path problem. Per the SOAP FAQ (http://xml.apache.org/soap/faq/index.html) there are two gotchas in WAS. It sounds like you need to revisit #2 below... 1.Explicitly set the port number that you have exposed the rpcrouter servlet on. Even if it is default(80), just mention it in the URL as http://aaa.bbb.ccc.ddd:port/soap/servlet/rpcrouter. 2.Verify that xerces is at the start of your path not only by setting it in the App but also in the websphere configuration files (admin.config, setupclient.bat). Shawn. megasycophant@ya To: [EMAIL PROTECTED] hoo.com cc: Subject: Problems on WAS 03/12/2002 02:31 PM Please respond to soap-user I've tried multiple code snippets on WAS v3.55 Standard that I know worked on Tomcat. I'm receiving the following response: http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"; xmlns:xsd="http://www.w3.org/1999/XMLSchema";> SOAP-ENV:Server.Exception: org.apache.xerces.dom.NodeImpl: method (Lorg/apache/xerces/dom/DocumentImpl;)V not found /mpd/soap/rpcrouter I've looked at the archives and seen similar problems but no resolution. TIA for any help! This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates.
Change management of web service input/output models???
What is the best way to deal with changes in the input and/or output model of a web service? Any references to general change management solutions are appreciated. In my case, there are n different groups implementing a SOAP service. If a new field is added to the input model all groups must simultaneously upgrade the input model definition (otherwise deserialization will fail once the model is changed in the client). Generally, however, the change will simply be the addition of a new field, not modifying or removing an existing field. Given this, a good solution is to allow legacy services to simply ignore the new field. This will allow the interested service implementor to recognize the new field while the other groups ignore it until they are ready to upgrade the input model. One solution is to subclass or create my own BeanSerializer which drops a field it doesn't recognize during deserialization (currently the Apache BeanSerializer will fail). I thought this was a good idea until I tried to find someone else who has done the same thing. I couldn't, which makes me think this may not be a good idea. Another is to flatten the input model to a Map such that all input models are just name/value pairs. I don't like this because the input model must be flattened. Lastly, I could add a new service accepting the new input model. This would require UDDI wrapper code in the client to direct the request to the appropriate version of the service. Any experiences or suggestions welcome. Thanks, Shawn. This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates.
Problem with deserialization of null objects
I have a simple service which takes one argument. When I pass null into the method it is deserialized as an EMPTY object in the SOAP service. It doesn't matter whether the object is a String or Vector or whatever. Using the TcpTunnelGui I can see that the attribute xsi:null="true" is correctly set during serialization. I am using WebSphere Studio Application Developer 4.0 (but not using the SOAP jar packaged with the IDE; instead I'm using Apache SOAP 2.2). I deployed the SOAP service to Tomcat and ran into the same problem. Any ideas? Shawn. This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates.
Implementation-independent services...
This is probably a pretty basic question but I'm not sure I should be implementing what the specification for the project defines... I am creating a system where different development groups are implementing a pre-defined SOAP service. It's possible that the service implementors will not use Java. There is a defined API for the SOAP service as follows: String getPublication( PublicationInputModel pim, EntitlementsModel em) The original architect specified that the objects should be passed in as XML instead of objects to support a non-Java SOAP service implementations. It seems to me that I should just publish the generated WSDL to the service implementors and that should be sufficient for them to implement the service in any language. Is that the correct way to do this? It also appears that using XML inputs (vs. objects) hampers discovery of services in a UDDI repository. Thanks, Shawn. This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates.
