[GUMP] Build Failure - Axis

This email is autogenerated from the output from: Build results exceed maximum length. Please see URL above for details. Last

cvs commit: xml-axis/java/src/org/apache/axis/utils Admin.java

gdaniels02/03/29 07:05:21 Modified:java/samples/echo EchoService.java deploy.wsdd java/src/org/apache/axis/client AdminClient.java java/src/org/apache/axis/description ServiceDesc.java java/src/org/apache/axis/utils Admin.java Log: Begin

Re: client.Service getCall()

I've had a chance to very briefly look at this and here are my thoughts: The problem stems that functions are needed from the "call" object which is not generally exposed by the client Stub object, and the need to make the Stub thread safe. - As I think we've all agreed if needed this needs to

Re: client.Service getCall()

make that: ((Call)soap).getResponseMessage().getSOAPPart().getAsString //dont know if still looks so natural :-) Rick Rineholt "The truth is out there... All you need is a better search engine!" [EMAIL PROTECTED]

Re: client.Service getCall()

In principle, I have no problems with this usage. If we can make it happen :-) Thanks, dims --- Rick Rineholt <[EMAIL PROTECTED]> wrote: > make that: > ((Call)soap).getResponseMessage().getSOAPPart().getAsString //dont > know if still looks so natural :-) > Rick Rineholt > "The truth is out the

NullPointer in BeanSerializer/BeanPropertyTarget

I have the following method within my Object which is mapped to BeanSerializer/Deserializer: public void setValidDates( java.util.ArrayList newValue ) { validDates = newValue; } During deserialization, I was getting the following error: - Could not convert [Ljava.lang.Object

Re: client.Service getCall()

The stubs are threadsafe wrt invocations. You've brought up that they're not wrt properties. But I don't believe it's possible to make a stub threadsafe wrt properties from INSIDE the stub. That's something that the stub caller must do. (This is essentially the reason why we instantiate a new

DO NOT REPLY [Bug 7612] New: - Java2WSDL does not work in some cases

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: client.Service getCall()

My one question is still is what is mandating that these objects be thread safe? Is it JAX-RPC ? If so then please point it out to me and ignore any of the following. If NOTHING is and we can do it at no cost great! It is my opinion that the most likely useage of a stub is somethng that is

Re: client.Service getCall()

JAX-RPC does not dictate stub thread safety. Users dictate it. Before the stub was thread-safe we had at least one axis-user post complaining that it wasn't safe. Granted, one user isn't much. BUT, based on WebSphere experience with CORBA stubs, thread-safety at the stub level is critical in c

service deployment minimum requirements

Title: service deployment minimum requirements Is this a correct statement? Assuming that JWS deployment is not used and Axis-based clients wish to invoke a service without using dynamic invocation (Service and Call objects), the following files, typically generated by WSDL2Java are generall

DO NOT REPLY [Bug 7621] New: - [wsdl2java] - Name conflict with java.lang.Exception

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 7621] - [wsdl2java] - Name conflict with java.lang.Exception

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 7311] - WSDL2Java generates wrong code

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: service deployment minimum requirements

Title: service deployment minimum requirements I forgot one class.  Is the class {port-name}BindingSkeleton generally required too? -Original Message-From: Volkmann, Mark Sent: Friday, March 29, 2002 1:48 PMTo: '[EMAIL PROTECTED]'Subject: service deployment minimum requirem

Re: client.Service getCall()

One item that "might" be broken from my understanding of the code; and I'd test it first in case I've missed something, is that the "session" logic I think its maintained by cookies that are kept in the MessageContext which is stored in the Call object. Creating a new Call object every time I

DO NOT REPLY [Bug 7625] New: - getPrefixes method in XMLUtils should be public

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: xml-axis/java/src/org/apache/axis/wsdl/toJava Emitter.java JavaBeanHelperWriter.java JavaDefinitionWriter.java JavaWriterFactory.java

scheu 02/03/29 14:13:06 Modified:java/src/org/apache/axis/encoding/ser BaseDeserializerFactory.java BaseSerializerFactory.java java/src/org/apache/axis/utils JavaUtils.java java/src/org/apache/axis/wsdl WSDL

cvs commit: xml-axis/java/src/org/apache/axis AxisFault.java AxisEngine.java

gdaniels02/03/29 15:25:01 Modified:java/src/org/apache/axis AxisFault.java AxisEngine.java Log: Prune a little dead code Revision ChangesPath 1.41 +0 -1 xml-axis/java/src/org/apache/axis/AxisFault.java Index: AxisFault.java ==

cvs commit: xml-axis/java/src/org/apache/axis/description ParameterDesc.java OperationDesc.java

gdaniels02/03/29 15:25:45 Modified:java/src/org/apache/axis/description ParameterDesc.java OperationDesc.java Log: Add constructors to allow quick initialization, and prune a little dead code. Revision ChangesPath 1.4 +16 -0 xml-axis/jav

cvs commit: xml-axis/java/src/org/apache/axis/description ServiceDesc.java

gdaniels02/03/29 15:26:36 Modified:java/src/org/apache/axis/description ServiceDesc.java Log: If we find a Skeleton class, ask it for an array of OperationDescs. Revision ChangesPath 1.9 +64 -49xml-axis/java/src/org/apache/axis/description/ServiceDesc.java

cvs commit: xml-axis/java/src/org/apache/axis/providers/java RPCProvider.java

gdaniels02/03/29 15:27:07 Modified:java/src/org/apache/axis/providers/java RPCProvider.java Log: Pruning Revision ChangesPath 1.51 +0 -43 xml-axis/java/src/org/apache/axis/providers/java/RPCProvider.java Index: RPCProvider.java ==

Skeletons

OK, here's my current thinking re: Skeletons and WSDL generation. When I last talked with Russell, he said the fact that Skeletons were classes was much more important than the particular API they used. Hence, I'm proposing we move to the following: interface Skeleton { } i.e. just a marker