Accessing HTTP headers
I need to access some HTTP header data from incoming web service requests. I’m using doc/lit style web services using Axis and Castor. If anyone can point me in the right direction I’d be most grateful. David
[axis2] data binding, xmlBeans, and M2 v 0.9x
I am attempting to use Axis2 with some fairly complex (large, lots of includes/imports, etc) schema and working through a few problems. While working through these issues I tend to iterate over the different versions of Axis (0.9 to M2) to understand if I am seeing consistent behavior (particularly for M2) and to see if different versions shed more light on a given problem. One difference between the 0.9 and M2 versions I have noticed is in the generation of stub/skeletons when using WSDL2Java. With M2 the data bindings don't seem to be generated automatically for you while in 0.9x they seem to be and I was hoping someone would have some insight into this issue. In particular an answer to the question if the direction of Axis2 is not to auto generate the data binding stubs, but instead allow the developer to use XmlBeans to generate the data bindings and then use those behind the default skeletons? This seems like a logical direction, but I was curious if it was an official direction. cheers
WSDL2Java: WSDLException INVALID_WSDL
Hello,
I'm trying to use WSDL2Java tool (Axis2) to generate the Java code from
a WSDL file. But when I run the tool, I receive the next error:
Exception in thread "main"
org.apache.axis2.wsdl.codegen.CodeGenerationException: Error parsing WSDL
at
org.apache.axis2.wsdl.codegen.CodeGenerationEngine.(CodeGenerationEngine.java:51)
at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:29)
at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:23)
Caused by: WSDLException (at
/wsdl:definitions/binding/operation[1]/input): faultCode=INVALID_WSDL:
Element '{http://schemas.xmlsoap.org/wsdl/}input' contained unexpected
attributes: 'message':
at com.ibm.wsdl.util.xml.DOMUtils.throwWSDLException(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseBindingInput(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseBindingOperation(Unknown
Source)at com.ibm.wsdl.xml.WSDLReaderImpl.parseBinding(Unknown
Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at
org.apache.axis2.wsdl.builder.wsdl4j.WSDL1ToWOMBuilder.readInTheWSDLFile(WSDL1ToWOMBuilder.java:154)
at
org.apache.axis2.wsdl.builder.wsdl4j.WSDL1ToWOMBuilder.build(WSDL1ToWOMBuilder.java:121)
at
org.apache.axis2.wsdl.builder.wsdl4j.WSDL1ToWOMBuilder.build(WSDL1ToWOMBuilder.java:94)
at
org.apache.axis2.wsdl.codegen.CodeGenerationEngine.getWOM(CodeGenerationEngine.java:118)
at
org.apache.axis2.wsdl.codegen.CodeGenerationEngine.(CodeGenerationEngine.java:49)
... 2 more
The WSDL part with the supossed error is:
http://www.w3.org/2002/03/xkms#wsdl";
xmlns:tns="http://www.w3.org/2002/03/xkms#wsdl";
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
xmlns="http://schemas.xmlsoap.org/wsdl/";
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns:xkms="http://www.w3.org/2002/03/xkms#";>
http://www.w3.org/2002/03/xkms#";
location='http://www.w3.org/TR/xkms2/Schemas/xkms.xsd'/>
http://schemas.xmlsoap.org/soap/http"; style="document"/>
* *
Any idea???
Thank you.
Vicente Guardiola
__
Renovamos el Correo Yahoo!
Nuevos servicios, más seguridad
http://correo.yahoo.es
Customizing the creating of Calendar objects
Hi, I am writing a web service client using Axis 1.2.1. Some of the fields in the web service are of the type xsd:dateTime, which wsdl2java has converted to java.util.Calendar. My problem is that the Calendar objects are created with the default time zone of the JVM, but I need them to be GMT. I can't set the global time tone to GMT because it will mess other parts in the application. Do you know how can I customize the deserialization of Calendar? David
RE: FW: Maven, the repository and Apache projects
And the repository line in the project.properties file should specify the repository? maven.repo.remote=http://www.ibiblio.org,http://maven-plugins.sf.net/mav en,http://www.apache.org/dist/java-repository/ I have this, and maven 1.0.2 complains: Attempting to download apache-axis-1.2.1.jar. Error retrieving artifact from [http://maven-plugins.sf.net/maven/apache-axis/jars/apache-axis-1.2.1.ja r]: java.io.IOExc eption: Unknown error downloading; status code was: 302 Note that it only tried the first repository in the path before giving up. -Original Message- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 23, 2005 3:07 PM To: axis-user@ws.apache.org Subject: Re: FW: Maven, the repository and Apache projects yes, Axis 1.2.1 is in the repo url mentioned below. On 8/23/05, Levitt, David, Bookspan <[EMAIL PROTECTED]> wrote: > Are the current Axis libraries staged to where Maven can easily retrieve > them? > > Should there be any special settings [repository url's] in Maven to use > them? > > -Original Message- > From: Carlos Sanchez [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 23, 2005 2:34 PM > To: Maven Users List > Subject: Re: Maven, the repository and Apache projects > > > Apache projects should release their projects also in the apache maven > repository. You should ask them to upload the jars to > http://www.apache.org/dist/java-repository/. > In case there's some problem or they have any doubts the can contact > me (carlos at apache dot org). > > Regards. > > On 8/23/05, Levitt, David, Bookspan <[EMAIL PROTECTED]> wrote: > > I'm adapting an existing project to Maven [1.0.2 for now] > > > > The build dependencies include several jakarta-commons and apache > > projects [log4j, axis], as well as legacy/third party libraries > [Dynamo > > app server, sun jsse] > > > > Maven was not able to download the recently released Apache Axis 1.2.1 > > library. [http://ws.apache.org/axis/] > > > > Is it a routine part of the Apache project workflow to place their > > output into the standard repository, so that Maven can retrieve them? > > > > If not, who is responsible for adding the project [Maven committers, > the > > other Apache project committers, the first user that encounters the > > issue, via a Jira request]? > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
FW: Maven, the repository and Apache projects
Are the current Axis libraries staged to where Maven can easily retrieve them? Should there be any special settings [repository url's] in Maven to use them? -Original Message- From: Carlos Sanchez [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 23, 2005 2:34 PM To: Maven Users List Subject: Re: Maven, the repository and Apache projects Apache projects should release their projects also in the apache maven repository. You should ask them to upload the jars to http://www.apache.org/dist/java-repository/. In case there's some problem or they have any doubts the can contact me (carlos at apache dot org). Regards. On 8/23/05, Levitt, David, Bookspan <[EMAIL PROTECTED]> wrote: > I'm adapting an existing project to Maven [1.0.2 for now] > > The build dependencies include several jakarta-commons and apache > projects [log4j, axis], as well as legacy/third party libraries [Dynamo > app server, sun jsse] > > Maven was not able to download the recently released Apache Axis 1.2.1 > library. [http://ws.apache.org/axis/] > > Is it a routine part of the Apache project workflow to place their > output into the standard repository, so that Maven can retrieve them? > > If not, who is responsible for adding the project [Maven committers, the > other Apache project committers, the first user that encounters the > issue, via a Jira request]? > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WSDL2Java broken in AXIS 1.2 FINAL
Having problems with Axis 1.2 FINAL. This used to work fine with
1.2RC3...
I am trying to use the WSDL2Java tool to generate Java sources from the
UDDI v3 WSDLs:
http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv3.
I get the following error during generation:
java.io.IOException: Type
{http://www.w3.org/2000/09/xmldsig#}SignatureProperty is referenced but
not defined.
at
org.apache.axis.wsdl.symbolTable.SymbolTable.checkForUndefined(SymbolTab
le.java:663)
at
org.apache.axis.wsdl.symbolTable.SymbolTable.add(SymbolTable.java:543)
at
org.apache.axis.wsdl.symbolTable.SymbolTable.populate(SymbolTable.java:5
16)
at
org.apache.axis.wsdl.symbolTable.SymbolTable.populate(SymbolTable.java:4
93)
at
org.apache.axis.wsdl.gen.Parser$WSDLRunnable.run(Parser.java:360)
at java.lang.Thread.run(Thread.java:534)
I'm using JDK 1.4.2_06.
I've verified that the obvious is not wrong: the type SignatureProperty
is DEFINITELY defined in the xmldsig schema. I've tried hosting the
xdsig schema remotely and locally, to no avail.
Any ideas?
dk
RE: happyaxis JAXP implementation found at an unknown location
Having problems with Axis 1.2 FINAL. This used to work fine with
1.2RC3...
I am trying to use the WSDL2Java tool to generate Java sources from the
UDDI v3 WSDLs:
http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm#uddiv3.
I get the following error during generation:
java.io.IOException: Type
{http://www.w3.org/2000/09/xmldsig#}SignatureProperty is referenced but
not defined.
at
org.apache.axis.wsdl.symbolTable.SymbolTable.checkForUndefined(SymbolTab
le.java:663)
at
org.apache.axis.wsdl.symbolTable.SymbolTable.add(SymbolTable.java:543)
at
org.apache.axis.wsdl.symbolTable.SymbolTable.populate(SymbolTable.java:5
16)
at
org.apache.axis.wsdl.symbolTable.SymbolTable.populate(SymbolTable.java:4
93)
at
org.apache.axis.wsdl.gen.Parser$WSDLRunnable.run(Parser.java:360)
at java.lang.Thread.run(Thread.java:534)
I'm using JDK 1.4.2_06.
I've verified that the obvious is not wrong: the type SignatureProperty
is DEFINITELY defined in the xmldsig schema. I've tried hosting the
xdsig schema remotely and locally, to no avail.
Any ideas?
dk
xsi:type attribute not set correctly
Dear all, We have a derived type from short in our schema such as: When sending an instance document (using document/literal) over the wire with axis (1.2), it is serialized as: 99 However, I this seems to be incorrect, as MyDerivedFromShort is derived (!) from xs:short but not xs:short itself. When parsing this with Xerces it will throw Validation error: LineNumber: 48 ColumnNumber: 2883 Message: cvc-elt.4.3: Type 'xsd:short' is not validly derived from the type definition, 'MyDerivedFromShortType', of element 'ns2:MyDerivedFromShort'.: I just upgraded to 1.2 final; as far as I can tell this bug was not present in the latest release candidate. Please let me know if I missed something or if there is any known workaround. Thanks! -dk
Axis and Castor - newbie question
I've been experimenting using Axis and Castor along the lines described in the IBM article: http://www-106.ibm.com/developerworks/webservices/library/ws-castor/ Everything's working fine, but I have a few questions: 1. I want to test that the WS messages are being validated against my schema (after all, this is one of the main reasons I'm using Castor rather than plain old WSDL2Java). My test set-up involves using the Castor generated code on the client and server side, so it's impossible to generate invalid XML! What's the simplest way to test this? 2. On the server side, I already have a set of DTOs that I must use internal to the app. So I'm currently having to translate between the Castor generated objects and my own DTOs, which is a pain. Ideally, I'd like Castor to unmarshall/marshall directly to/from my DTOs. I've read the provided Castor XML Mapping documentation but I can't see how to integrate my Castor XML mapping file into my Axis+Castor solution. Can this be done? 3. If the answer to 2. is yes, can the incoming WS request messages and the outgoing WS response messages still be validated against my schema? If the answer to 2 & 3 is yes, yipp! Thanks for any help, David
Re: License for wsdl2java output?
I agree entirely -- I feel strongly that the output of wsdl2java should
be public domain so users can slap whatever license they want on it. It
just wasn't obvious to me (or more correctly I didn't think it would be
obvious to all the lawyers in the world :-) that this was already the
case.
David
On Wed, 2005-04-20 at 13:10 +0530, Venkat Reddy wrote:
> I'm not sure if it is good idea for axis to impose licensing on
> generated code. For example, if a dataEclispe generates some bootstrap
> java code from its templates for a POJO or web app, which you later
> modify for your needs, which licence applies to the code? IMO, Same
> should hold good for wsdl2java, except that the amount and complexity
> of gerated code is more here. I think its upto the user of the
> wsdl2java to apply their own license.
>
> - venkat
>
>
> On 4/19/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> > I don't think we impose any license on the generated code. Do you want
> > us to make this explicit in our docs? (Please open a JIRA issue if you
> > think we should)
> >
> > thanks,
> > dims
> >
> > On 4/19/05, David Kaelbling <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > What license is code generated by wsdl2java under? Apache 2.0? Public
> > > domain? I couldn't find an explicit reference in the docs.
> > >
> > > Thanks,
> > > David
> > >
> > > --
> > > David KAELBLING 100 Beaver St., Waltham MA 02453-8425
> > > <[EMAIL PROTECTED]> 781-891-5100 ext 121, fax -5145
> > >
> > >
> > >
> >
> > --
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> >
>
--
David KAELBLING 100 Beaver St., Waltham MA 02453-8425
<[EMAIL PROTECTED]> 781-891-5100 ext 121, fax -5145
signature.asc
Description: This is a digitally signed message part
License for wsdl2java output?
Hi,
What license is code generated by wsdl2java under? Apache 2.0? Public
domain? I couldn't find an explicit reference in the docs.
Thanks,
David
--
David KAELBLING 100 Beaver St., Waltham MA 02453-8425
<[EMAIL PROTECTED]> 781-891-5100 ext 121, fax -5145
signature.asc
Description: This is a digitally signed message part
A solution to deploy Axis 1.2 on WebSphere 5.1 with PARENT_FIRST classloading...
Greetings,
I know that
deploying Axis 1.2 on WebSphere 5.1 has been a frequent topic on this
list, so I thought I would add my findings to the
noise.
I am deploying Axis
1.2RC3 in a war that resides within an ear. The axis jars are in the
war/WEB-INF/lib dir. For various reasons related to the other
contents of my ear, I must use PARENT_FIRST classloading. As many have
reported, if you have PARENT_FIRST classloading on WebSphere 5.1 with Axis
1.2RC3, then there is a conflict between the version of saaj (1.1) that ships
with WebSphere, and the version of saaj (1.2) that Axis 1.2RC3 expects, and you
get the following exception:
java.lang.IncompatibleClassChangeError: class
org.apache.axis.SOAPPart does not implement interface
org.w3c.dom.Document
This issue can be
resolved with PARENT_LAST classloading and a manifest which specifies the
classpath...but for those of use who can't use PARENT_LAST classloading, there
is another option.
After some digging
in the Axis code, it appears that a single source code change to Axis will
eliminate the issue altogether. The offending code is in
org.apache.axis.message.MessageElement.addTextNode(), and can be patched as
follows:
OLD
CODE:
public SOAPElement
addTextNode(String s) throws SOAPException {
try { Text
text =
getOwnerDocument().createTextNode(s);
((org.apache.axis.message.Text)text).setParentElement(this);
return this; } catch
(ClassCastException e)
{ throw
new SOAPException(e);
}}
PATCHED
CODE:
public SOAPElement
addTextNode(String s) throws SOAPException
{
try { Text
text = new
org.apache.axis.message.Text(s);
appendChild(text);
return this; } catch
(ClassCastException e)
{ throw
new SOAPException(e);
}}
After making this
change, Axis 1.2RC3 will run on WebSphere 5.1 with PARENT_FIRST classloading,
and no exceptions will be thrown.
-DT
-
David Tompkins
Sr. Computer Scientist
Adobe Systems, Inc.
tompkins
_AT_ adobe _DOT_
com
RE: [Fwd: Re: axis stubs]
Hi Chad, Thanks for taking some interest in this, I'm glad other people have had similar issues. I agree that Java interfaces for the exposed business logic should drive everything... I really hate the communication layer affecting the internal business logic, it makes me feel really dirty working with code which doesn't hold to this (I was recently brought in late to a project which gave me a JAXB/base64 experience which just makes me shudder thinking about it). Thanks for an interest, I'm glad to see that other people have had a similar need. The solution we're working on now is just to modify the stubs generated so that they extend from the original interface. We've got an algorithm now for doing this which works, and just have to put together the code which ties the generated interface and complex type representations back to the original interface. We could have modified the existing Wsdl2Java task to do this, but just chose to post process the source files instead (what can I say, I'd rather use Java regex then learn the internals of the wsdl2java tool, though later I may have to). Cheers, David L -Original Message- From: Chad Woolley [mailto:[EMAIL PROTECTED] Sent: Monday, 21 March 2005 6:10 PM To: [EMAIL PROTECTED] Subject: [Fwd: Re: axis stubs] David, Read my post on 3-16 titled "Can Wsdl2Java make the stub implement a specified interface?", it's related. I think the appropriate way to do this is to generate a java interface file which matches the generated class, and is implemented by it. These could then be copied and used in client or test code, without having to make a concrete dependency on either the stub or the original class. The generated interface name could be the original class name with an I prepended (even though I don't like that convention), or made configurable. I think this is a valid requirement, because I often auto-generate java stubs for use in my test code, but use the original beans in that same test code, thus encountering the namespace conflicts you describe (same class, different packages). Also, if you have client code which depends on the stubs, it is cleaner and more testable to be able to make it depend on an interface rather than a concrete class. FYI, I also have automated code in my build script (Maven) which can automatically build a war from the current project, deploy it, and invoke Wsdl2Java (with a couple of hacks) to automatically generate the stubs. You can also run it against an external war or deployed war. This is really nice if you want to use the stubs during testing, or automatically keep the stubs up-to-date with the wsdl. I'd dig in and try to do this if I had more time or perhaps if an axis dev showed interest in this. Thanks, Chad Woolley ** The Distillery Pty Limited ABN 69 080 932 467 PO Box 940, Dickson ACT 2602, AUSTRALIA Phone: +61 2 6272 0200 Fax: +61 2 6262 5151 Web: www.thedistillery.com.au The Distillery Inc 2111 Wilson Blvd, Suite 700, Arlington, Virginia 22201, USA Phone: +1 703 351 5082 Web: www.thedistilleryinc.com The Distillery (Europe) Ltd 53 Chandos Place London WC2N 4HS Tel: +44 (0)20 7812 6692 Fax: +44 (0)20 7812 6677 - The information contained in this email and any files attached may be confidential and/or copyrighted information of The Distillery, Third Parties and/or the intended recipient and may be the subject of legal privilege or public interest immunity. You may only reproduce or distribute the material if you are expressly authorised by us to do so. If you are not the intended recipient, any use, disclosure, copying, circulation, forwarding, printing or publication of this message or attached files is strictly forbidden. If you have received this document in error or are not an intended recipient, please notify the sender and delete from your Inbox and/or system. The Distillery does not represent or warrant that files attached to this e-mail are free from computer viruses or other defects and liability is limited to the resupply (or cost of resupply) of the attached files. -
RE: axis stubs
I can use the -p switch, but that just means that my packages are different. Whilst this works, the generated files are not tied to the original interface (a new one is generated). -Original Message- From: Elaine Nance [mailto:[EMAIL PROTECTED] Sent: Wednesday, 16 March 2005 3:18 AM To: axis-user@ws.apache.org Subject: Re: axis stubs Are you using the -p (package) switch with WSDL2Java? David Levy wrote: > Hi, > > I've been working on a project where we must generate client axis stubs for > code which we maintain. This means that we generate the WSDL via java2wsdl, > then generate the stubs with wsdl2java. This all works fine, but the problem > is that the client stubs generated with wsdl2java adhere to a different > interface then the original interface. Both interfaces are almost identical, > but do not adhere to the same java interface. > > Example: > Original Interface: com.original.WidgetStore#getWidget(String id): > com.original.Widget > Generated Interface: com.generated.WidgetStore#getWidget(String id): > com.generated.Widget > > There are a few problems with the current solution (lesser of evils); > either, (1) both interfaces have exactly the same package name and are > duplicates, or (2) the interfaces are different, and clients of the stubs > cannot cast the returned stubs to the original interface. > > I'm going to have to do this over and over again for many types of services, > so I need a general solution I can automate. I've been thinking of solutions > which manipulate the java source code to modify the generated client stubs > so that they do adhere to the same interface, but was wondering if there was > possibly another way? > > Thanks if you've read this far, and let me know if I didn't explain my > problem well enough. > > Cheers, > > David L > > > > The Distillery Pty Limited > ABN 69 080 932 467 > PO Box 940, Dickson ACT 2602, AUSTRALIA > Phone: +61 2 6272 0200 > Fax: +61 2 6262 5151 > Web: www.thedistillery.com.au > > The Distillery Inc > 2111 Wilson Blvd, Suite 700, > Arlington, Virginia 22201, USA > Phone: +1 703 351 5082 > Web: www.thedistilleryinc.com > > The Distillery (Europe) Ltd > 53 Chandos Place London WC2N 4HS > Tel: +44 (0)20 7812 6692 > Fax: +44 (0)20 7812 6677 > > > - > The information contained in this email and any files attached may be > confidential and/or copyrighted information of The Distillery, Third > Parties and/or the intended recipient and may be the subject of legal > privilege or public interest immunity. You may only reproduce or > distribute the material if you are expressly authorised by us to do > so. If you are not the intended recipient, any use, disclosure, > copying, circulation, forwarding, printing or publication of this > message or attached files is strictly forbidden. > > If you have received this document in error or are not an intended > recipient, please notify the sender and delete from your Inbox and/or > system. > > The Distillery does not represent or warrant that files attached to > this e-mail are free from computer viruses or other defects and > liability is limited to the resupply (or cost of resupply) of the > attached files. > - > > -- <~~ | Computers are useless. They can only give you answers. | -- Pablo Picasso -- <~~ The Distillery Pty Limited ABN 69 080 932 467 PO Box 940, Dickson ACT 2602, AUSTRALIA Phone: +61 2 6272 0200 Fax: +61 2 6262 5151 Web: www.thedistillery.com.au The Distillery Inc 2111 Wilson Blvd, Suite 700, Arlington, Virginia 22201, USA Phone: +1 703 351 5082 Web: www.thedistilleryinc.com The Distillery (Europe) Ltd 53 Chandos Place London WC2N 4HS Tel: +44 (0)20 7812 6692 Fax: +44 (0)20 7812 6677 - The information contained in this email and any files attached may be confidential and/or copyrighted information of The Distillery, Third Parties and/or the intended recipient and may be the subject of legal privilege or public interest immunity. You may only reproduce or distribute the material if you are expressly authorised by us to do so. If you are not the intended recipient, any use, disclosure, copying, circulation, forwarding, printing or publication of this message or attached files is strictly forbidden. If you have received this document in error or are not an intended recipient, please notify the sender and delete from your Inbox and/or system. The Distillery does not represent or warrant that files attached to this e-mail are free from computer viruses or other defects and liability is limited to the resupply (or cost of resupply) of the attached files. -
axis stubs
Hi, I've been working on a project where we must generate client axis stubs for code which we maintain. This means that we generate the WSDL via java2wsdl, then generate the stubs with wsdl2java. This all works fine, but the problem is that the client stubs generated with wsdl2java adhere to a different interface then the original interface. Both interfaces are almost identical, but do not adhere to the same java interface. Example: Original Interface: com.original.WidgetStore#getWidget(String id): com.original.Widget Generated Interface: com.generated.WidgetStore#getWidget(String id): com.generated.Widget There are a few problems with the current solution (lesser of evils); either, (1) both interfaces have exactly the same package name and are duplicates, or (2) the interfaces are different, and clients of the stubs cannot cast the returned stubs to the original interface. I'm going to have to do this over and over again for many types of services, so I need a general solution I can automate. I've been thinking of solutions which manipulate the java source code to modify the generated client stubs so that they do adhere to the same interface, but was wondering if there was possibly another way? Thanks if you've read this far, and let me know if I didn't explain my problem well enough. Cheers, David L The Distillery Pty Limited ABN 69 080 932 467 PO Box 940, Dickson ACT 2602, AUSTRALIA Phone: +61 2 6272 0200 Fax: +61 2 6262 5151 Web: www.thedistillery.com.au The Distillery Inc 2111 Wilson Blvd, Suite 700, Arlington, Virginia 22201, USA Phone: +1 703 351 5082 Web: www.thedistilleryinc.com The Distillery (Europe) Ltd 53 Chandos Place London WC2N 4HS Tel: +44 (0)20 7812 6692 Fax: +44 (0)20 7812 6677 - The information contained in this email and any files attached may be confidential and/or copyrighted information of The Distillery, Third Parties and/or the intended recipient and may be the subject of legal privilege or public interest immunity. You may only reproduce or distribute the material if you are expressly authorised by us to do so. If you are not the intended recipient, any use, disclosure, copying, circulation, forwarding, printing or publication of this message or attached files is strictly forbidden. If you have received this document in error or are not an intended recipient, please notify the sender and delete from your Inbox and/or system. The Distillery does not represent or warrant that files attached to this e-mail are free from computer viruses or other defects and liability is limited to the resupply (or cost of resupply) of the attached files. -
Axis Performance
Hello, I have recently completed a series of simple performance measurements for Apache Axis. I wanted to share the results and see if I could get any new insights on the data. To check out the results you should go to the following URL: http://www.atl.external.lmco.com/projects/QoS/compare/dist_oo_compare_ipc.html Here you will see a tool developed here at Lockheed Martin's Advanced Technology Laboratory for comparing various forms of IPC. There are a ton of results for all different types of middleware solutions. You can browse through them by looking at the links in the left frame. If you want to go directly to the various SOAP results please use the filter located at the top of the left frame. You can enter the word 'xml', without the quotes, into the box and hit enter. All of our recent results for web services should appear. It should look something like this: smp/ web-service-and-xml-rpc/ apache-axis/ v1.1_attachments v1.1_dime v1.1_inline apache-xml-rpc/ v1.2-b1 XSOAP/ v1.2.23 First and foremost, if you click on the "apache-axis/" link you will get our attempt at a detailed explanation of all the conditions in which these tests were conducted. You can then look at the three sets of results my clicking on either, SOAP with attachments, DIME, or simple base64 encoded messages(byte arrays). All of our tests are simple round trip latency tests that involve sending a message of x bytes and waiting for an acknowledgment. We time this exchange for a size of x varying from 4 to 65536 on every power of 2. The results you are looking at should all be 1 million samples for each message size. I have attached a graph I made real quick using the above tool. It contains a comparison of apache-axis to a couple other middleware's. These include basic tcp, apache implementation of xml-rpc, XSOAP (aka soaprmi), and the TAO orb. We are trying to understand a number of things. Firstly, where is the large overhead coming from? Obviously the use of XML in the SOAP protocol makes for more verbose messages. In addition, we also considered the creation of a new connection for each RPC(we are currently looking into developing some simple tests to examine this issue). Are these two issues enough to explain this kind of overhead or are we not considering something? Secondly, if you look closely at the curves for XSOAP and apache-axis base64 messages they are extremely similar. We do not usually see results that are this close when testing two different implementations of any middleware. Would anyone know of a specific reason why these two implementations would be so close? Finally, you can see that there is a break in performance of axis with attachments and DIME at around 16384 size messages. We are assuming this is because that is when axis begins writing temp files for every attachment to the attachments/ directory. Is there a way to turn this behavior off? Thanks for reading this long email and I am anxious to here any comments or questions. David Turner ATL<>
