[jira] Commented: (AXIS-2158) Error attempting to use DIME in Axis client
[ http://issues.apache.org/jira/browse/AXIS-2158?page=comments#action_12356880 ] Ami Fischman commented on AXIS-2158: I was seeing the same problem until I changed the wsdd on both client and server to use CommonsHTTPSender instead of HTTPSender. Once I did this (and added commons-httpclient-3.0-rc3.jar) everything seems fine. I modified the EchoAttachment sample to use a chunk size of 1024 bytes and files as big as 100M work fine. Is there a repro case that still sees this behavior with CommonsHTTPSender? > Error attempting to use DIME in Axis client > --- > > Key: AXIS-2158 > URL: http://issues.apache.org/jira/browse/AXIS-2158 > Project: Apache Axis > Type: Bug > Components: SAAJ > Versions: 1.2.1 > Environment: Axis 1.2.1client running jdk1.4.2_05 and Tomcat 5.0 for server. > Reporter: Brian Husted > > Sending more than eight DIME chunks from an Axis client to Axis server > results in the following error: > Caused by: java.io.IOException: End of physical stream detected when more > DIME chunks expected. > at > org.apache.axis.attachments.DimeDelimitedInputStream._read(DimeDelimitedInputStream.java:268) > > at > org.apache.axis.attachments.DimeDelimitedInputStream.read(DimeDelimitedInputStream.java:201) > > at > org.apache.axis.attachments.DimeDelimitedInputStream.read(DimeDelimitedInputStream.java:445) > > at > org.apache.axis.attachments.ManagedMemoryDataSource.(ManagedMemoryDataSource.java:146) > > at > org.apache.axis.attachments.MultiPartDimeInputStream.readTillFound(MultiPartDimeInputStream.java:163) > > ... 46 more > at > org.apache.axis.encoding.DeserializationContext.getObjectByRef(DeserializationContext.java:619) > > at > org.apache.axis.encoding.ser.JAFDataHandlerDeserializer.startElement(JAFDataHandlerDeserializer.java:70) > > at > org.apache.axis.encoding.DeserializationContext.startElement(DeserializationContext.java:1048) > > 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:236) > at org.apache.axis.message.RPCElement.getParams(RPCElement.java:384) > at > org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:148) > > at > org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:323) > ... 33 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Axis2] Road Map for next release
Hi All, It's partly my fault that ADB did not get tested with Amazon or Google or any other widely used WSDLs. However ADB does not understand SOAP encoding (!) and the Google service cannot be directly codegned. One other limitation of ADB is that it does not support imports (yet) which I intend to fix before the end of this indigo plugfest (with the hope of using ADB for Indigo interoperability as well) In the mean time anyone is welcome to write test cases for testing the ADB stuff. I've already written some reflection based tests (these tests have to be reflection based since the code generates during the build!) and are in the org.apache.axis2.databinding.schema.populate package in the test folder of the codegen module. te:On Thu, 2005-11-03 at 13:34 -0500, Tom Jordahl wrote > What I would hope is that ADB can be used with a typical WSDL found in> the wild – UDDI, Amazon.com, Google, etc, etc. If it doesn't work> with the WSDL users are likely to want to consume, then they will just > walk away. Or maybe they will figure out how to use XMLBeans. Maybe.Oh absolutely- if ADB doesn't work with Google, Amazon, Salesforce,Yahoo etc. then its no use at all. Can you help identify a set of "widely used" services like that that need to be test cases? I've askedfor that repeatedly but there haven't been many responses. If we have aset of WSDLs that'll help identify what features need to work and which are not needed for "normal use".Sanjiva.-- Ajith Ranabahu
RE: [Axis2] Road Map for next release
On Thu, 2005-11-03 at 13:34 -0500, Tom Jordahl wrote > What I would hope is that ADB can be used with a typical WSDL found in > the wild – UDDI, Amazon.com, Google, etc, etc. If it doesn’t work > with the WSDL users are likely to want to consume, then they will just > walk away. Or maybe they will figure out how to use XMLBeans. Maybe. Oh absolutely- if ADB doesn't work with Google, Amazon, Salesforce, Yahoo etc. then its no use at all. Can you help identify a set of "widely used" services like that that need to be test cases? I've asked for that repeatedly but there haven't been many responses. If we have a set of WSDLs that'll help identify what features need to work and which are not needed for "normal use". Sanjiva.
RE: StAX API (http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html) and AXIS 2.0
I am trying to use Axis2 migrating from Axis1.3. And am trying to generate code, but i get follwoing. It seems like the way axis is using this might need to be modified. I don't know if this is a defect or what, can someone more knowledgeable with code look into this. build.xml:24: org.apache.axis2.wsdl.codegen.CodeGenerationException: java.lang.RuntimeException: org.apache.xmlbeans.XmlException: Thread main: The 0th supplied input is not a schema document: its type is N= Reference Thread http://mail-archives.apache.org/mod_mbox/xml-xmlbeans-user/200407.mbox/[EMAIL PROTECTED] Thanks, Parikh, Pratik From: Jayaraman, Venkatesh [mailto:[EMAIL PROTECTED] Sent: Saturday, November 05, 2005 1:17 PMTo: Jayaraman, Venkatesh; axis-user@ws.apache.orgSubject: RE: StAX API (http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html) and AXIS 2.0 How much speed we will gain in Axis 2.0 over (Axis 1.2 and Axis 1.3) ? Also In Axis 1.2 RC3, is parser reuse is turned on by default to increase the performance? -Venky From: Jayaraman, Venkatesh Sent: Saturday, November 05, 2005 11:14 AMTo: 'axis-user@ws.apache.org'Subject: StAX API (http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html) and AXIS 2.0 What is new in Axis 2.0 version? Speed - Axis2 is based on StAX API(http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html), which gives greater speed than SAX event base parsing that has been used in Axis1.2 Stability - Axis2 has fixed phases and for extensions an area of user defined phases. This allows far more stability and flexibility than Axis1.x. Transport framework - Simple abstraction designing of transports (i.e., senders and listeners for SOAP over various protocols such as SMTP, etc), allow far more flexibility and the core of the engine is completely transport-independent. WSDL Support - Axis2 supports version 1.1 and 2.0, which allow creating stubs and skeletons, to manipulate web service arena. Component - Oriented Architecture - This is merely through archives (.mar and .aar) . Easily reusable components such as Handlers, Modules allow patterns processing for your applications, or to distribute to partners. Axis2 more concern on the "Module" concept rather Handler concept. Modules contain handlers that have been ordered through phase rules. which being ordered to specific service(s). Why stAX (not SAX) parsing? The Streaming API for XML (StAX) allows not only parsing of XML documents but also writing XML documents to an output stream. Until recently, programmers had only two choices when creating XML documents programmatically. Their first option was to directly write serialized XML content to the output stream, and the second was to use DOM. Both options have severe drawbacks. In the first case, the programmer is fully responsible for ensuring that the resulting document is well formed. The programmer must take care of details such as matching start and end tags or the escaping of special characters, such as the less than sign (<) and the ampersand (&), in character content. This can make the implementation of programs tedious and error prone. DOM, on the other hand, frees the programmer from this burden but introduces considerable overhead: The complete document must first be constructed as a node tree in memory before it can be serialized to an output stream. The Streaming API for XML (StAX) completely changes this. Unlike the Simple API for XML (SAX), StAX offers an API for writing XML documents. To be precise, it offers two APIs: a low-level, cursor-based API (XMLStreamWriter), and a higher-level, event-based API (XMLEventWriter). While the cursor-based API is best used in data binding scenarios (for example, creating a document from application data), the event-based API is typically used in pipelining scenarios where a new document is constructed from the data of input documents. StAX does not guarantee well-formed documents. It is still possible to produce a document that violates the XML recommendation, such as a document with several root elements or several XML prologues, or tag and attribute names containing whitespace or characters not supported by XML. StAX implementations may check these issues but they are not required to do so (the reference implementation doesn't). Nevertheless, the StAX XMLStreamWriter is a big improvement over outputting raw XML data, and it does this at a fraction of the cost of using DOM. --Venky CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distrib
Re: [Axis2]New Feature - Sending same message to more than One Recepcient
Hi All, Here's my view on this. If I remember right there was some discussion way back on this and it ended up with the understanding that something like this ends up with a pub-sub architecture. So what I think is that this multiplexing could be handled as a different transport which abstracts all addressing and other QOS issues. The particular transport sender also handles subscriptions so Axis wouldn't know anything about it! On 11/5/05, Chathura Herath <[EMAIL PROTECTED]> wrote: Actually i am trying to implement this kind of transport multiplexingthing for some other project and one further problem that i faced washow to handle the addressing stuff. So IMO multiplexing should startat the addressing out handler because the addressing headers are different for the out going messages. This is kind of messy though andkills the grace of the SOAP processing model. Further the niceapplication for this, which would be WS-notification and WS-Eventingboth have ws addressing around. Actually Eran think of a Notification framework where you have 20Notification consumers. So instead of making 20 call invocations wecan write a transport (or an addressing handler) such that it willdeliver the same message to the different Notification consumers(20). call.setToList(eprList);call.invokeBlocking(...) So the message will go through the soap processing model only once.So only one OM for the most part. There are other complications likedifferent consumers requiring different policies, but from my personal experience of Notification and eventing i know that almost all thenotifications that are sent out are same except for the addressingheaders.Believe me this feature would come in handy when we eventually implement Notification and eventing.Chathura.On 11/5/05, Eran Chinthaka <[EMAIL PROTECTED]> wrote:> Hi Srinath,>> can't wedo this by changing the toEPR in the Call api and invoke the > method ? Sorry if I understood this wrong.>> for example;> call.setTo(eprOne)> call.ivokeBlocking(.);>> call.setTo(eprTwo)> call.invokeBlocking(...)> >>> Srinath Perera wrote:>> >Hi All;> >> >Shall we add a support to users to send same message to more than one> >recipients?> >> >Motivate for the doing this is if we need to send same message to 20 > >recipients, (e.g. Publish Subscribe) . If user create 20 Calls it will> >be very expensive and if we do the thingy inside Axis2 we can set the> >OM caching true and reuse at least part of the Message to multiple > >invocations.> >> >I do not feel this should be done at the transport sender level (e.g.> >We need different addressing properties). I feel we should have> >different Pipe for each while sharing the same SOAP Body. I think > >about something like MultiOutClient (or PublisherClient .. I am not> >sure ) add to Client API> >> >I am thinking aloud :), this could actually get very complex> >thoughts? > >> >Thanks> >> >Srinath> >> >> >> >>>--Chathura Herathhttp://www.bloglines.com/blog/chathurah -- Ajith Ranabahu
[jira] Created: (AXIS-2291) WSDL2Java does not embed annotations in JavaDoc comments for some generated classes
WSDL2Java does not embed annotations in JavaDoc comments for some generated classes --- Key: AXIS-2291 URL: http://issues.apache.org/jira/browse/AXIS-2291 Project: Apache Axis Type: Bug Components: WSDL processing Versions: 1.3 Environment: Mac OS X 10.4.3, java full version "1.4.2_09-232" Reporter: Allen Cronce Priority: Minor We have annotations in our XSD in order to document the code generated. But for some classes, WSDL2Java does not embed the annotation text in the JavaDoc comments of the generated. code. With the wsdl example below, the wsdl annotation for BirthDayType does make it into the BirthDayType.java generated code. But the annotation for CountingType does not make it into the CountingType.java generated code. Here's the sample wsdl that demonstrates the problem: http://schemas.xmlsoap.org/wsdl/http/"; xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"; xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; xmlns="http://schemas.xmlsoap.org/wsdl/"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:wsdlns="axisprob.wsdl" xmlns:xsdns="axisprob.xsd" xmlns:xml="http://www.w3.org/XML/1998/namespace";> http://www.w3.org/XML/1998/namespace"; schemaLocation="http://www.w3.org/2001/xml.xsd"/> http://www.w3.org/2001/XMLSchema"; xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";> This type demonstrates an enumeration type. For some reason this text does not make it into the JavaDoc comments for the class generated. This is a type definition for a birthday minus the year. Note that this text does make it into the JavaDoc comments. Can you see me? Can you see me? http://schemas.xmlsoap.org/soap/http"/> http://localhost:4310/WebObjects/axisprob2.woa/wa/axisprob2"/> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AXIS-2290) Code generated by WSDL2Java references non-existent NMTokenHolder class
Code generated by WSDL2Java references non-existent NMTokenHolder class --- Key: AXIS-2290 URL: http://issues.apache.org/jira/browse/AXIS-2290 Project: Apache Axis Type: Bug Components: WSDL processing Versions: 1.3 Environment: Mac OS X 10.4.3, java full version "1.4.2_09-232" Reporter: Allen Cronce Priority: Minor It looks like when you're using document wrapped style and have more than one out or inout parameters, Axis wants to wrap any outputted class in a "holder" class. That makes sense. But in this case of my sample wsdl below, the code generated passes a org.apache.axis.holders.NMTokenHolder to the AxisprobSOAPBindingImpl.problemMessage method. This causes build errors because there is no NMTokenHolder class. There is only a TokenHolder class. I've worked around the problem by manually editing the generated code to change the undefined NMTokenHolder to TokenHolder classes. But it's bothersome that Axis is generating code for classes that don't exist. Here's a sample wsdl that reproduces the problem: http://schemas.xmlsoap.org/wsdl/http/"; xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"; xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; xmlns="http://schemas.xmlsoap.org/wsdl/"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:wsdlns="axisprob.wsdl" xmlns:xsdns="axisprob.xsd"> http://www.w3.org/XML/1998/namespace"; schemaLocation="http://www.w3.org/2001/xml.xsd"/> http://www.w3.org/2001/XMLSchema"; xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";> This is a type definition for generic text in XML. For maintenance reasons, it is preferable to use something like this rather than the built-in datatype string, unless you have an absolute requirement to use a simple datatype. This is a type definition for globally unique identifiers. This is a type definition for globally unique identifiers. NEEDS COMMENT NEEDS COMMENT http://schemas.xmlsoap.org/soap/http"/> http://localhost:4310/WebObjects/axisprob2.woa/wa/axisprob2"/> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AXIS-2289) WSDL2Java error with wsdl that references "xml:specialAttrs"
WSDL2Java error with wsdl that references "xml:specialAttrs" Key: AXIS-2289 URL: http://issues.apache.org/jira/browse/AXIS-2289 Project: Apache Axis Type: Bug Components: WSDL processing Versions: 1.3 Environment: Mac OS X 10.4.3, java full version "1.4.2_09-232" Reporter: Allen Cronce When I use the Axis 1.3 WSDL2Java to generate the server side classes, I get the following error: Parsing XML file: axisprob.wsdl java.io.IOException: Type specialAttrs is referenced but not defined. at org.apache.axis.wsdl.symbolTable.SymbolTable.checkForUndefined(SymbolTable.java:665) at org.apache.axis.wsdl.symbolTable.SymbolTable.add(SymbolTable.java:545) at org.apache.axis.wsdl.symbolTable.SymbolTable.populate(SymbolTable.java:518) at org.apache.axis.wsdl.symbolTable.SymbolTable.populate(SymbolTable.java:495) at org.apache.axis.wsdl.gen.Parser$WSDLRunnable.run(Parser.java:361) at java.lang.Thread.run(Thread.java:552) The issue that that WSDL2Java's got a problem with specialAttrs, which is an attribute group defined by the w3c. I'm importing the xml.xsd schema where specialAttrs is defined. When I previously generated code with Axis 1.1, this error did not happen. Further, other validation tools think that the wsdl is fine. Here's a sample wsdl that reproduces the problem: http://schemas.xmlsoap.org/wsdl/http/"; xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"; xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; xmlns="http://schemas.xmlsoap.org/wsdl/"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:wsdlns="axisprob.wsdl" xmlns:xsdns="axisprob.xsd"> http://www.w3.org/XML/1998/namespace"; schemaLocation="http://www.w3.org/2001/xml.xsd"/> http://www.w3.org/2001/XMLSchema"; xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";> This is a type definition for generic text in XML. For maintenance reasons, it is preferable to use something like this rather than the built-in datatype string, unless you have an absolute requirement to use a simple datatype. This is a type definition for globally unique identifiers. This is a type definition for globally unique identifiers. NEEDS COMMENT NEEDS COMMENT http://schemas.xmlsoap.org/soap/http"/> http://localhost:4310/WebObjects/axisprob2.woa/wa/axisprob2"/> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-2285) Deserializing objects on client side with unknown data members from server side causes exception, makes server code harder to maintain
[
http://issues.apache.org/jira/browse/AXIS-2285?page=comments#action_12356845 ]
Geir Egil Hansen commented on AXIS-2285:
Maybe you are right about that Tom ("changing the contract").
However, most of the clients I tried does not complain when adding a new
datamember to the class.
So far only Axis client code does.
What is the rest of the problem?
> Deserializing objects on client side with unknown data members from server
> side causes exception, makes server code harder to maintain
> --
>
> Key: AXIS-2285
> URL: http://issues.apache.org/jira/browse/AXIS-2285
> Project: Apache Axis
> Type: Bug
> Components: Serialization/Deserialization
> Versions: 1.3
> Environment: Windows XP
> Reporter: Geir Egil Hansen
>
> Example:
> I make a class on the server side. The class contains some data members.
> Like
> class MyClass{
>String str1;
> }
> Some clients are generated uses the WSDL file.
> In the next server version I need to add another datamember to the class:
> class MyClass{
>String str1;
>String str2;
> }
> Then the Axis client based on the previous version throws an exception. The
> exception is thrown from the class BeanDeserializer at around line 250. And
> the code doing it is like this:
> if (propDesc == null) {
> throw new SAXException( Messages.getMessage("badElem00",
> javaType.getName(), localName));
> return null;
> }
> Throwing an exception here in the client makes it impossible to extend the
> functionality on the server side. I have tested .NET clients, other Java
> clients, Borland C++ Builder and none of them throws any exception. And I
> think it is wrong to throw any here, because the client code is supposed to
> deserialize any datamembers it knwos about. It does need what it does not
> know anything about. It would be a different matter if an existing datameber
> was removed in the new version (like str1 was removed in the example). THEN
> an exception must be thrown.
> I think this is a bug and should be fixed. Now we ask our customers if they
> are to use Axis to generate the client, and if they are, we give them a new
> version of the BeanSerializer.java where the code is changed to
> if (propDesc == null) {
> //@TODO: No such field. Throwing exception here makes
> code not backwards compatible.
> log.warn("No such field in client code: " +
> javaType.getName() + "/" + localName);
> //throw new SAXException(
> //Messages.getMessage("badElem00", javaType.getName(),
> // localName));
> return null;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
