DataHandler/Attachment
Hi, I am using a DataHandler object to send a serialized object in a file to the webservice. But the way of how I do this is inefficient, because I write the serialized object to file and then I send it to the service as an attachment. I am using the following Constructor DataHandler(new FileDataSource(filename)). On the server-side the service read the file and deserializes the object and uses the object. I had see that it is possible to use a another Constructor of DataHandler: DataHandler (java.lang.Objectobj, java.lang.StringmimeType) Create a DataHandler instance representing an object of this MIME type. I want to do something like ByteArrayOutputStream baos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(baos); ContentID contentID = new HashValue1(null, banu); oos.writeObject(contentID); DataHandler dhSource = new DataHandler(baos, application/octet-stream); csService.addContent(dhSource); Does anybody have some experiences, if its right how I want to do this. Iam not sure if its possible? Where can I see which MIME Types are offered. Regards Ferruh
Deploy service from interface probs
All,
I was wondering if anyone could help.
I am deploying a service from an interface that I have created, but my
enumerations are just converted to strings in the generated classes
even though they are declared as enumerations in the wsdl.
i.e .
genterated wsdl
simpleType name=Benefit
restriction base=soapenc:string
enumeration value=Defined Contribution/
enumeration value=Defined Benefit/
/restriction
/simpleType
complexType name=ArrayOf_tns5_Benefit
complexContent
restriction base=soapenc:Array
attribute ref=soapenc:arrayType wsdl:arrayType=tns5:Benefit[]/
/restriction
/complexContent
/complexType
complexType name=SPensionSchemeDetails
complexContent
extension base=tns2:SVersioned
sequence
...
element
name=benefitsProvided nillable=true
type=impl:ArrayOf_tns5_Benefit/
...
But the generated classes there is just a string array..
public class SPensionSchemeDetails extends
com.anite.borris.webservice.service.impl.SVersioned implements
java.io.Serializable {
private java.lang.String[] benefitsProvided;
...
}
and the deploy.wsddd maps them as strings
typeMapping
xmlns:ns=http://enumerations.customtypes.schemereturn.om.borris.anite.com
qname=ns:Benefit
type=java:java.lang.String
serializer=org.apache.axis.encoding.ser.SimpleSerializerFactory
deserializer=org.apache.axis.encoding.ser.SimpleDeserializerFactory
encodingStyle=http://schemas.xmlsoap.org/soap/encoding/
/
I am missing something? Why doesnt it use an enumeration type mapping or create a enumeration[] instead of a string[]?
cheers
Mike-- If we can hit that bull's-eye, the rest of the dominos will fall like a house of cards - Checkmate.
classloader problem
I've a problem with classloader.
I got all the time CastClassException when I invoke directly a stub (Axis 1.2)
on a JAAS module (Java authentication).
It seems the problem is on this line (WSDDTargetedChain.java:157):
pivot = (Handler)ClassUtils.forName(pivotQName.getLocalPart()).newInstance();
the cast Handler is not from the same instance of result and throw a CastClass
Exception.
What can I do to prevent this frustrating problem?
I really need your help!
Thank you all!
- ERROR ---
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: java.lang.ClassCastException
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:java.lang.ClassCastException
at
org.apache.axis.deployment.wsdd.WSDDTargetedChain.makeNewInstance(WSDDTargetedChain.java:157)
at
org.apache.axis.deployment.wsdd.WSDDDeployableItem.getNewInstance(WSDDDeployableItem.java:274)
at
org.apache.axis.deployment.wsdd.WSDDDeployableItem.getInstance(WSDDDeployableItem.java:260)
at
org.apache.axis.deployment.wsdd.WSDDDeployment.getTransport(WSDDDeployment.java:394)
at
org.apache.axis.configuration.FileProvider.getTransport(FileProvider.java:257)
at org.apache.axis.AxisEngine.getTransport(AxisEngine.java:332)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:163)
at org.apache.axis.client.Call.invokeEngine(Call.java:2765)
at org.apache.axis.client.Call.invoke(Call.java:2748)
at org.apache.axis.client.Call.invoke(Call.java:2424)
at org.apache.axis.client.Call.invoke(Call.java:2347)
at org.apache.axis.client.Call.invoke(Call.java:1804)
at
com.jcms.Axis.WSPortal.WS_AcessoPortalSoapStub.verificaAutenticacao(WS_AcessoPortalSoapStub.java:321)
at com.jcms.Axis.Webservices.VerificaAutenticacao(Webservices.java:263)
at jaas.module.SampleLoginModule.login(SampleLoginModule.java:214)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:675)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:129)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:610)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:607)
at javax.security.auth.login.LoginContext.login(LoginContext.java:534)
at org.apache.catalina.realm.JAASRealm.authenticate(JAASRealm.java:316)
at
org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:229)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at java.lang.Thread.run(Thread.java:534)
{http://xml.apache.org/axis/}hostname:bvg
java.lang.ClassCastException
at org.apache.axis.AxisFault.makeFault(AxisFault.java:101)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:216)
at org.apache.axis.client.Call.invokeEngine(Call.java:2765)
at org.apache.axis.client.Call.invoke(Call.java:2748)
at org.apache.axis.client.Call.invoke(Call.java:2424)
at org.apache.axis.client.Call.invoke(Call.java:2347)
at org.apache.axis.client.Call.invoke(Call.java:1804)
at
Exception: java.net.ConnectException: Connection refused ache axis web services
Hi I am getting the given error while deploying client program(Axis Fibonacci application). Can u solve the problem? java.net.ConnectException: Connection refused apache axis web services
WSDL describing attachments
Hi, I am an Axis C++ committer and I am implementing attachment support in Axis C++. I am describing attachments in the WSDL using either the WSDL MIME bindings or the types under the http://xml.apache.org/xml-soap namespace. Where is there documentation for the types in the http://xml.apache.org/xml-soap namespace? Why did Axis/Java decide to support the types under the http://xml.apache.org/xml-soap namespace instead of the WSDL MIME bindings? Can anyone help me? Mark Mark Whitlock IBM
memory consumption on client side
We have performance problems retrieving about 1 objects from the server. We notice an enormous memory consumption on the client side 300MB. Are there any settings to speed up and reduce the memory footprint? Haug
Re: classloader problem
In a discussion about error handling a while back, I mentioned to James
Taylor how insane it is to report a ClassCastException without citing the
offending class.
Presumably you know which class your handler is or can look it up in the
handler element of your deployment descriptor. You need to ensure that it
implements org.apache.axis.Handler, one way or another.
If that doesn't help, make sure your log4j.properties file of configured to
dump in DEBUG mode and check out the log for clues.
(I wonder if anyone has every estimated how much Java development time is
wasted globally on class path issues.)
Jeff
- Original Message -
From: BVG [EMAIL PROTECTED]
To: axis-user@ws.apache.org
Sent: Tuesday, June 14, 2005 8:06 AM
Subject: classloader problem
I've a problem with classloader.
I got all the time CastClassException when I invoke directly a stub (Axis
1.2) on a JAAS module (Java authentication).
It seems the problem is on this line (WSDDTargetedChain.java:157):
pivot =
(Handler)ClassUtils.forName(pivotQName.getLocalPart()).newInstance();
the cast Handler is not from the same instance of result and throw a
CastClass Exception.
What can I do to prevent this frustrating problem?
I really need your help!
Thank you all!
- ERROR ---
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: java.lang.ClassCastException
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:java.lang.ClassCastException
at
org.apache.axis.deployment.wsdd.WSDDTargetedChain.makeNewInstance(WSDDTarget
edChain.java:157)
at
org.apache.axis.deployment.wsdd.WSDDDeployableItem.getNewInstance(WSDDDeploy
ableItem.java:274)
at
org.apache.axis.deployment.wsdd.WSDDDeployableItem.getInstance(WSDDDeployabl
eItem.java:260)
at
org.apache.axis.deployment.wsdd.WSDDDeployment.getTransport(WSDDDeployment.j
ava:394)
at
org.apache.axis.configuration.FileProvider.getTransport(FileProvider.java:25
7)
at org.apache.axis.AxisEngine.getTransport(AxisEngine.java:332)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:163)
at org.apache.axis.client.Call.invokeEngine(Call.java:2765)
at org.apache.axis.client.Call.invoke(Call.java:2748)
at org.apache.axis.client.Call.invoke(Call.java:2424)
at org.apache.axis.client.Call.invoke(Call.java:2347)
at org.apache.axis.client.Call.invoke(Call.java:1804)
at
com.jcms.Axis.WSPortal.WS_AcessoPortalSoapStub.verificaAutenticacao(WS_Acess
oPortalSoapStub.java:321)
at com.jcms.Axis.Webservices.VerificaAutenticacao(Webservices.java:263)
at jaas.module.SampleLoginModule.login(SampleLoginModule.java:214)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:675)
at
javax.security.auth.login.LoginContext.access$000(LoginContext.java:129)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:610)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:607)
at javax.security.auth.login.LoginContext.login(LoginContext.java:534)
at org.apache.catalina.realm.JAASRealm.authenticate(JAASRealm.java:316)
at
org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthent
icator.java:229)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase
.java:446)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137
)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:104)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118
)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:109)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
Webservice GateWay How to implement ?
Hi all, I am using tomcat 5.x and axis 1.2 for my webservices . I want to implement webservice Gateway now , how do i proceed with it. can you give me some clue of how tostart with it or some resource to look it because as the way it is explained in Ibm alphaworks, I understand that it is the functionality provided by application server is that so? plz correct me if I am wrong . Thanks and Regards, krthekeyan.s
AXIS 1.2 / Style Wrapped / array operation arguments
Hello. Just for a confirmation... I'm testing again the wrapped style services, with different kid of arguments and return types. It seems, for what my server side class receives, that the client call doesn't make difference to marshall null and empty array arguments. For example, for an operation with the java signature : public void testArrayOfInteger(int[] values) the two invocations on the service stub : testArrayOfInteger(null) or testArrayOfInteger(new int[0]) produce, for the server class invocation a null argument. It seems to be the same for arrays of objects, like strings or custom types. For the moment, this doesn't represent a real problem, but i'd like to know if this behaviour is natural, or may be a wsdl default or a bug... This tests are all done with wrapped/literal style services. I don't know if other style/use produce the same... Thanks. -- Ephemeris Lappis -- Philippe Maseres
Re: Webservice GateWay How to implement ?
What do you want your gateway to do? I would not say that an app server provides gateway services or vice versa. Anne On 6/14/05, Krthekeyan Suriyanarayanan [EMAIL PROTECTED] wrote: Hi all, I am using tomcat 5.x and axis 1.2 for my webservices . I want to implement webservice Gateway now , how do i proceed with it. can you give me some clue of how tostart with it or some resource to look it because as the way it is explained in Ibm alphaworks, I understand that it is the functionality provided by application server is that so? plz correct me if I am wrong . Thanks and Regards, krthekeyan.s
RE: AXIS 1.2 / Style Wrapped / array operation arguments
My test on document/literal doesn't show this behaviour. With document/literal, I have tried with string, Integer and byte[], all worked fine. -Feng -Original Message- From: Ephemeris Lappis [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 1:41 PM To: Axis-User Subject: AXIS 1.2 / Style Wrapped / array operation arguments Hello. Just for a confirmation... I'm testing again the wrapped style services, with different kid of arguments and return types. It seems, for what my server side class receives, that the client call doesn't make difference to marshall null and empty array arguments. For example, for an operation with the java signature : public void testArrayOfInteger(int[] values) the two invocations on the service stub : testArrayOfInteger(null) or testArrayOfInteger(new int[0]) produce, for the server class invocation a null argument. It seems to be the same for arrays of objects, like strings or custom types. For the moment, this doesn't represent a real problem, but i'd like to know if this behaviour is natural, or may be a wsdl default or a bug... This tests are all done with wrapped/literal style services. I don't know if other style/use produce the same... Thanks. -- Ephemeris Lappis -- Philippe Maseres
RE: AXIS 1.2 / Style Wrapped / array operation arguments
Few weeks ago, all my tests used document/literal style, but i don't remember how the empty arrays were exchanged, if i tested it. I could test the same services with document style to compare the results, but i suppose a confirmation of this behaviour should be a good thing... -- Ephemeris Lappis -Original Message- From: Feng Xie (fxie) [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 8:10 PM To: axis-user@ws.apache.org Subject: RE: AXIS 1.2 / Style Wrapped / array operation arguments My test on document/literal doesn't show this behaviour. With document/literal, I have tried with string, Integer and byte[], all worked fine. -Feng -Original Message- From: Ephemeris Lappis [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 1:41 PM To: Axis-User Subject: AXIS 1.2 / Style Wrapped / array operation arguments Hello. Just for a confirmation... I'm testing again the wrapped style services, with different kid of arguments and return types. It seems, for what my server side class receives, that the client call doesn't make difference to marshall null and empty array arguments. For example, for an operation with the java signature : public void testArrayOfInteger(int[] values) the two invocations on the service stub : testArrayOfInteger(null) or testArrayOfInteger(new int[0]) produce, for the server class invocation a null argument. It seems to be the same for arrays of objects, like strings or custom types. For the moment, this doesn't represent a real problem, but i'd like to know if this behaviour is natural, or may be a wsdl default or a bug... This tests are all done with wrapped/literal style services. I don't know if other style/use produce the same... Thanks. -- Ephemeris Lappis -- Philippe Maseres
Message serialization issue
Hi all, I ran into an issue when passing around javax.xml.soap.SOAPMessage of type org.apache.axis.Message over live wire. It fails over RMI because it does not like javax.xml.soap.MimeHeaders. I think MimeHeaders is part of org.apache.axis.Message but cannot be serialized whereas org.apache.axis.Message implements serializable. How can I unset MimeHeaders part of org.apache.axis.Message so that I can pass around SOAPMessage object. SOAPMessage messsage; MessageFactory factory = MessageFactory.newInstance(); // message points to object of type org.apache.axis.Message message = factory.createMessage(); SOAPPart soapPart = (org.apache.axis.SOAPPart) message.getSOAPPart(); // Here I set contect of mysource soapPart.setContent(mysource); message.saveChanges(); return message; This message when returned over RMI causes NotSerializable exception. I appreciate any pointers. Thanks in advance. -Akash.
RE: AXIS 1.2 / Style Wrapped / array operation arguments
I'm testing it with document style, and my first results show a different behaviour : the empty arrays are correctly passed to and from the called service. Thus, it seems to be a wrapped style stubs problem... I have not done all the tests in document style, since an old problem is coming back for multiple arguments operation. I have few information for the moment, and i'll post a new mail when i get more. I have a fault exception on the client side when it calls an operation like : int operation(int, int), operation that perfectly works in wrapped style... Perhaps you have an idea ?! Just for the information, the exception thrown back on the client side is : java.lang.NullPointerException at org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:2 21) at org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:12 8) at org.apache.axis.encoding.DeserializationContext.endElement(DeserializationCo ntext.java:1087) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1675) at org.apache.crimson.parser.Parser2.content(Parser2.java:1926) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1654) at org.apache.crimson.parser.Parser2.content(Parser2.java:1926) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1654) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:634) at org.apache.crimson.parser.Parser2.parse(Parser2.java:333) at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:448) at javax.xml.parsers.SAXParser.parse(SAXParser.java:345) at org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext .java:227) at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696) at org.apache.axis.Message.getSOAPEnvelope(Message.java:424) at org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstandChe cker.java:62) at org.apache.axis.client.AxisClient.invoke(AxisClient.java:206) at org.apache.axis.client.Call.invokeEngine(Call.java:2765) at org.apache.axis.client.Call.invoke(Call.java:2748) at org.apache.axis.client.Call.invoke(Call.java:2424) at org.apache.axis.client.Call.invoke(Call.java:2347) at org.apache.axis.client.Call.invoke(Call.java:1804) at my.service3.TestServicePortSoapBindingStub.testIntegerPairToInteger(Unknown Source) at my.client.Main.testIntegerPairToInteger(Main.java:123) at my.client.Main.main(Main.java:215) And the origin exception on the server side : java.lang.NullPointerException at org.apache.axis.AxisFault.makeFault(AxisFault.java:101) at org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:329) at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java: 32) at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) at org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:453) at org.apache.axis.server.AxisServer.invoke(AxisServer.java:281) at org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:699) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java: 327) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:643) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:2 46) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180 ) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
using Axis client with HTTP/1.1 and pipeling
Hi, I heard that it requires some extra work to make Axis client work with HTTP/1.1. Let's assume it works with HTTP/1.1, how does it take advantage of HTTP/1.1 's pipelinig feature ? Given the fact that each client call is a synchronized call. My understanding is that even you could have multiple threads to call mulitple stub methods "simultaneously", those Soap requests would be sent over multiple *different* connections, instead of pipelined into a single connection. Any hint on this will be appreciated. Feng
The tests generated files from maven axis:wsdl2java don't run...
How can I make the JUnit tests from the wsdl2java goal run when I build? They are currently in the ./target/axis/tests DIR and nothing run each time. 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)
Re: including site docs into war??? How?
Well yes, but is there not a standard way in maven to include them into the war? I can easily enough run maven site, but the war should include it automatically right? From: C.C. Ang [EMAIL PROTECTED] Reply-To: axis-user@ws.apache.org To: axis-user@ws.apache.org Subject: Re: including site docs into war??? How? Date: Wed, 15 Jun 2005 09:39:19 +1000 On Tue, Jun 14, 2005 at 04:23:24PM -0700, Mick Knutson wrote: 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) Cant u just jar it in? or is that not what you mean? -- | mailto:[EMAIL PROTECTED] | +61 3 9233 8302 | Yahoo IM : cangatwork | Children seldom misquote you. In fact, they usually repeat word for | word what you shouldn't have said. - Utiba Pty Ltd This message has been scanned for viruses and dangerous content by Utiba mail server and is believed to be clean. 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)
Re: Message serialization issue
Why are you trying to send SOAP messages over RMI? That makes no sense at all. Anne On 6/14/05, Akash Agrawal [EMAIL PROTECTED] wrote: Hi all, I ran into an issue when passing around javax.xml.soap.SOAPMessage of type org.apache.axis.Message over live wire. It fails over RMI because it does not like javax.xml.soap.MimeHeaders. I think MimeHeaders is part of org.apache.axis.Message but cannot be serialized whereas org.apache.axis.Message implements serializable. How can I unset MimeHeaders part of org.apache.axis.Message so that I can pass around SOAPMessage object. SOAPMessage messsage; MessageFactory factory = MessageFactory.newInstance(); // message points to object of type org.apache.axis.Message message = factory.createMessage(); SOAPPart soapPart = (org.apache.axis.SOAPPart) message.getSOAPPart(); // Here I set contect of mysource soapPart.setContent(mysource); message.saveChanges(); return message; This message when returned over RMI causes NotSerializable exception. I appreciate any pointers. Thanks in advance. -Akash.
Re: including site docs into war??? How?
On Tue, Jun 14, 2005 at 04:41:11PM -0700, Mick Knutson wrote: Well yes, but is there not a standard way in maven to include them into the war? I can easily enough run maven site, but the war should include it automatically right? Maven? I thought this was an axis A... crossposted. I dont use Maven but I'm sure it should do what you want as it doesnt sound like an unreasonable thing to want to do. Sorry... no help here. Chai -- | mailto:[EMAIL PROTECTED] | +61 3 9233 8302 | Yahoo IM : cangatwork | Poetry, beauty, romance, love--these are what we stay alive for. | ... You are here. Life exists. The powerful play goes on, and you | may contribute a verse. What will your verse be? - Robin Williams | in Dead Poet's Society - Utiba Pty Ltd This message has been scanned for viruses and dangerous content by Utiba mail server and is believed to be clean.
RE: AXIS 1.2 / Style Wrapped / array operation arguments
Hello again. I've done more tests again, with my int[] operation(int[]) operation, passing an empty array, and the results are : - with rpc/encoded : ok - with document/literal : ok - with wrapped/literal : not ok, a null reference is received on the server side, instead of the empty array. In fact, the tests also use other operations with other types of arrays with strings or custome types, and the result is the same. So, a confirmation is welcome, this is a bug or not, or a wrapped style logical behaviour. Thanks. -- Ephemeris Lappis -Original Message- From: Feng Xie (fxie) [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 8:28 PM To: axis-user@ws.apache.org Subject: RE: AXIS 1.2 / Style Wrapped / array operation arguments Ephemeris : Please let me know if you see any result with document/literal different from what I described. Thanks, -Feng -Original Message- From: Ephemeris Lappis [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 2:22 PM To: axis-user@ws.apache.org Subject: RE: AXIS 1.2 / Style Wrapped / array operation arguments Few weeks ago, all my tests used document/literal style, but i don't remember how the empty arrays were exchanged, if i tested it. I could test the same services with document style to compare the results, but i suppose a confirmation of this behaviour should be a good thing... -- Ephemeris Lappis -Original Message- From: Feng Xie (fxie) [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 8:10 PM To: axis-user@ws.apache.org Subject: RE: AXIS 1.2 / Style Wrapped / array operation arguments My test on document/literal doesn't show this behaviour. With document/literal, I have tried with string, Integer and byte[], all worked fine. -Feng -Original Message- From: Ephemeris Lappis [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 14, 2005 1:41 PM To: Axis-User Subject: AXIS 1.2 / Style Wrapped / array operation arguments Hello. Just for a confirmation... I'm testing again the wrapped style services, with different kid of arguments and return types. It seems, for what my server side class receives, that the client call doesn't make difference to marshall null and empty array arguments. For example, for an operation with the java signature : public void testArrayOfInteger(int[] values) the two invocations on the service stub : testArrayOfInteger(null) or testArrayOfInteger(new int[0]) produce, for the server class invocation a null argument. It seems to be the same for arrays of objects, like strings or custom types. For the moment, this doesn't represent a real problem, but i'd like to know if this behaviour is natural, or may be a wsdl default or a bug... This tests are all done with wrapped/literal style services. I don't know if other style/use produce the same... Thanks. -- Ephemeris Lappis -- Philippe Maseres
