Re: CalClient giving Exception
Did you get the latest source from svn? Deepak D [EMAIL PROTECTED] 15/12/2005 04:05 Please respond to Apache AXIS C User List To axis-c-dev@ws.apache.org cc Subject CalClient giving Exception HI All, I build Axis C++ calclient on Windows. I followed build and setup instructions as per Axis C++ Windows Developers Guide. In xsd__int Calculator::add(xsd__int Value0, xsd__int Value1)function when it calls if (AXIS_SUCCESS != m_pCall-initialize(CPP_RPC_PROVIDER)) it is giving exception AXISC_NODE_VALUE_MISMATCH_EXCEPTION. Apache server is running and I can get page of http://localhost/axis Please let me know what me the problem at the earliest. With Regards Deepak _ A Camera Sells every 2 Minutes on eBay. Get Your's at a Great Price Now! http://adfarm.mediaplex.com/ad/ck/4686-26272-10936-699?ck=Cameras
Re: Axis2 Deployment Options
put the shared objects in a jar in the axis2/WEB-INF/lib folder I think it works On 12/14/05, Todd Orr [EMAIL PROTECTED] wrote: Also, how would you version the services now? I used to be able to create a separate war with a different url-pattern based on version. Now that services are deployed under one war, how can I differentiate? On 12/14/05, Todd Orr [EMAIL PROTECTED] wrote: Also, how do you share global objects now? I used to be able to create an entire war and share any objects I needed to. Now that the services are in individual aar files, where do I put the shared objects? On 12/14/05, Todd Orr [EMAIL PROTECTED] wrote: The changes in the deployment options from Axis1 to Axis2 are very disruptive. The web admin for uploading new services is nice for testing, but makes my company's deployment scripts useless. The fact that the aar files need to be placed in the exploded axis2 war's services directory makes deployment a real pain. Axis1 was very simple and easy to use since it was only a regular webapp. I've been reading through the docs, and I do not see any other deployment options. Has anyone found any better ways to deploy axis2 services?
Re: problem in getting WSDL
Hi, According to whatI know (Correct me if I'm wrong), Axis2 still does not support WSDL generation. Inorder to get the wsdl in http://.../myservice?wsdl you have to provide your own wsdl inside the aar file... If you have the WSDL file corresponding to the Web service, rename it to service.wsdl and put that into theMETA-INF directory. (It is not necessary to have a wsdl file in Axis2.) The following article might help you... http://www.developer.com/open/print.php/10930_3557741_2 HTH, ~Thilina On 12/15/05, thilina madu [EMAIL PROTECTED] wrote: Hi all, 1. I don't know how to take the WSDL from the myself written service. 2. I deployed my.. .aar file intheservices folder.That service is working nicley with java client.But now I want access that from .NET client to do that I want to take wsdl. whenI(brows by using thius http://localhost:8080/axis2)go serrvice link that show all the method my services.but once I go to the link corresponding to the service then it giev XML document telling WSDL is not available. Why like that. If you know any method totakeWSDL onceafter deployingthe servicein axis2 .please send me . Any kind of response is higly appreciated 3.How can I make a java or .Net proxy to achve interopoerability. madushan thilina Yahoo! ShoppingFind Great Deals on Holiday Gifts at Yahoo! Shopping -- May the SourcE be with uhttp://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ http://www.bloglines.com/blog/Thilina
Re: AXIS client, applet, socket:// problem
Hi guys,
I don't want to offend anybody, but is this a stupid question or a hard
one? I didn't receive any replies and I must say I googled a few hours
searching for an answer, so it might be a hard question (?).
Best regards,
George.
George Mardale wrote:
Hi everybody,
I use axis1.3 and JDK1.5.0 to develop an applet that calls a
webservice (the webservice is very simple, it calculates the sum of 2
integers and returns it to the client) and handles its response. The
applet and all required jars are signed, they are downloaded on the
client side without problems.
When the applet invokes the webservice, using the following method call:
Integer ret = (Integer) call.invoke( new Object[] { i1, i2 } );
the following log messages appear in the browser's java console:
security: Loading certificates from Deployment session certificate
store
security: Loaded certificates from Deployment session certificate
store
security: Loading certificates from Internet Explorer
TrustedPublisher certificate store
security: Loaded certificates from Internet Explorer
TrustedPublisher certificate store
security: Checking if certificate is in Deployment permanent
certificate store
network: Connecting socket://www.delsyne.ro:80 with proxy=DIRECT
(- this connection causes me problems)
network: Connecting
http://www.delsyne.ro/evsMonitoring/intBeanInfo.class with proxy=HTTP
@ delsyne.ro/82.79.170.47:3128
network: Connecting
http://www.delsyne.ro/evsMonitoring/intBeanInfo.class with cookie
Bugzilla_login=2; Bugzilla_logincookie=2; DEFAULTFORMAT=specific
The problem with the socket:// call is that in some environments
users are behind a proxy, which only accepts http://; requests. Thus,
all calls to socket://... with proxy=... fail with the message:
Can't connect to SOCKS proxy. Connection refused, because their
proxy does not accept socket requests.
Is there a way to force axis not to make socket:// requests?
Normally, I would have expected axis to use only http/https, but
seeing socket protocol in the console puzzles me a little bit... Since
socket:// appears only when invoke method is call, it's reasonable
enough to think that AXIS generates this socket:// request.
Is there another solution for this problem? Clearly, I'm missing
someting in here...
Thank you for your time,
George.
Re: AXIS client, applet, socket:// problem
I can't help much but can offer some advice.
I've done a fair amount of socket programming and never even seen a prefix '
socket:// ' . Signed jars from an applet make it even more of a specialized
question. I suggest posting the question on a general java forum like
comp.lang.java.programmer . Place 'signed jars' 'applet' and ' socket:// ' in
the message and your likely to get a response. That might be able to narrow
your question down to where it becomes more of a general axis question.
Just my .02 cents.
iksrazal
Em Quinta 15 Dezembro 2005 09:21, o George Mardale escreveu:
Hi guys,
I don't want to offend anybody, but is this a stupid question or a hard
one? I didn't receive any replies and I must say I googled a few hours
searching for an answer, so it might be a hard question (?).
Best regards,
George.
George Mardale wrote:
Hi everybody,
I use axis1.3 and JDK1.5.0 to develop an applet that calls a
webservice (the webservice is very simple, it calculates the sum of 2
integers and returns it to the client) and handles its response. The
applet and all required jars are signed, they are downloaded on the
client side without problems.
When the applet invokes the webservice, using the following method call:
Integer ret = (Integer) call.invoke( new Object[] { i1, i2 } );
the following log messages appear in the browser's java console:
security: Loading certificates from Deployment session certificate
store
security: Loaded certificates from Deployment session certificate
store
security: Loading certificates from Internet Explorer
TrustedPublisher certificate store
security: Loaded certificates from Internet Explorer
TrustedPublisher certificate store
security: Checking if certificate is in Deployment permanent
certificate store
network: Connecting socket://www.delsyne.ro:80 with proxy=DIRECT
(- this connection causes me problems)
network: Connecting
http://www.delsyne.ro/evsMonitoring/intBeanInfo.class with proxy=HTTP
@ delsyne.ro/82.79.170.47:3128
network: Connecting
http://www.delsyne.ro/evsMonitoring/intBeanInfo.class with cookie
Bugzilla_login=2; Bugzilla_logincookie=2; DEFAULTFORMAT=specific
The problem with the socket:// call is that in some environments
users are behind a proxy, which only accepts http://; requests. Thus,
all calls to socket://... with proxy=... fail with the message:
Can't connect to SOCKS proxy. Connection refused, because their
proxy does not accept socket requests.
Is there a way to force axis not to make socket:// requests?
Normally, I would have expected axis to use only http/https, but
seeing socket protocol in the console puzzles me a little bit... Since
socket:// appears only when invoke method is call, it's reasonable
enough to think that AXIS generates this socket:// request.
Is there another solution for this problem? Clearly, I'm missing
someting in here...
Thank you for your time,
George.
Re: AXIS client, applet, socket:// problem
Hi,
thanks a lot for your feedback...
In order to make things easier to understand, here is an excerpt from
the java console with axis log level set to debug:
- org.apache.axis.i18n.resource::handleGetObject(setMsgForm)
- org.apache.axis.i18n.resource::handleGetObject(setMsgForm)
- Setting current message form to: FORM_OPTIMIZED (currentMessage is
now org.apache.axis.utils.ByteArray)
- Setting current message form to: FORM_OPTIMIZED (currentMessage is
now org.apache.axis.utils.ByteArray)
- Exit: SOAPPart::saveChanges(): [EMAIL PROTECTED]
- Exit: SOAPPart::saveChanges(): [EMAIL PROTECTED]
- Enter: SOAPPart::saveChanges
- Enter: SOAPPart::saveChanges
- Enter: SOAPPart::saveChanges
- Enter: SOAPPart::saveChanges
network: Connecting socket://www.delsyne.ro:80 with proxy=DIRECT
- org.apache.axis.i18n.resource::handleGetObject(createdHTTP00)
- org.apache.axis.i18n.resource::handleGetObject(createdHTTP00)
- Created an insecure HTTP connection
- Created an insecure HTTP connection
- org.apache.axis.i18n.resource::handleGetObject(xmlSent00)
- org.apache.axis.i18n.resource::handleGetObject(xmlSent00)
- XML sent:
- XML sent:
- ---
- ---
- Enter: SOAPPart::saveChanges
- Enter: SOAPPart::saveChanges
- POST /axis/Calculator.jws HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related,
text/*
.
I couldn't locate an explicit socket usage in the axis implementation,
but the socket:// seems to appear "in the proximity" of
HttpSender.getSocket() method call in HttpSender.writeToSocket(). It
could be a side-effect of signed jars/applets, as you stated... I will
check the other mailing list...
Thanks again for your advice,
George.
iksrazal wrote:
I can't help much but can offer some advice.
I've done a fair amount of socket programming and never even seen a prefix '
socket:// ' . Signed jars from an applet make it even more of a specialized
question. I suggest posting the question on a general java forum like
comp.lang.java.programmer . Place 'signed jars' 'applet' and ' socket:// ' in
the message and your likely to get a response. That might be able to narrow
your question down to where it becomes more of a general axis question.
Just my .02 cents.
iksrazal
Em Quinta 15 Dezembro 2005 09:21, o George Mardale escreveu:
Hi guys,
I don't want to offend anybody, but is this a stupid question or a hard
one? I didn't receive any replies and I must say I googled a few hours
searching for an answer, so it might be a hard question (?).
Best regards,
George.
George Mardale wrote:
Hi everybody,
I use axis1.3 and JDK1.5.0 to develop an applet that calls a
webservice (the webservice is very simple, it calculates the sum of 2
integers and returns it to the client) and handles its response. The
applet and all required jars are signed, they are downloaded on the
client side without problems.
When the applet invokes the webservice, using the following method call:
Integer ret = (Integer) call.invoke( new Object[] { i1, i2 } );
the following log messages appear in the browser's java console:
security: Loading certificates from Deployment session certificate
store
security: Loaded certificates from Deployment session certificate
store
security: Loading certificates from Internet Explorer
TrustedPublisher certificate store
security: Loaded certificates from Internet Explorer
TrustedPublisher certificate store
security: Checking if certificate is in Deployment permanent
certificate store
network: Connecting socket://www.delsyne.ro:80 with proxy=DIRECT
(- this connection causes me problems)
network: Connecting
http://www.delsyne.ro/evsMonitoring/intBeanInfo.class with proxy=HTTP
@ delsyne.ro/82.79.170.47:3128
network: Connecting
http://www.delsyne.ro/evsMonitoring/intBeanInfo.class with cookie
"Bugzilla_login=2; Bugzilla_logincookie=2; DEFAULTFORMAT=specific"
The problem with the "socket://" call is that in some environments
users are behind a proxy, which only accepts "http://" requests. Thus,
all calls to "socket://... with proxy=..." fail with the message:
"Can't connect to SOCKS proxy. Connection refused", because their
proxy does not accept socket requests.
Is there a way to force axis not to make "socket://" requests?
Normally, I would have expected axis to use only http/https, but
seeing socket protocol in the console puzzles me a little bit... Since
"socket://" appears only when invoke method is call, it's reasonable
enough to think that AXIS generates this "socket://" request.
Is there another solution for this problem? Clearly, I'm missing
someting in here...
Thank you for your time,
George.
Re: getPrefix() problem with axis 1.3?
Hi Cooper, I sense that you don't have a proper QName class available in your classpath. This could be very much the case when some other applications jar file which implemented QName is present ahead in the classpath. Make sure you have the latest jaxrpc.jar and that too first in the classpath thanother application jars. Regards Jaya On 12/14/05, Cooper, Jeremy [EMAIL PROTECTED] wrote: Hello,I have noticed a few posts regarding the exception below that occurrswhile running WSDL2Java.Is there a resolution or work around for this issue?I have ensured that I have the correct wsdl4j jar, although I can onlyfind the class in the jaxrpc jar.[axis-wsdl2java] java.lang.NoSuchMethodError:javax.xml.namespace.QName.getPrefix()Ljava/lang/String; [axis-wsdl2java]atorg.apache.axis.wsdl.symbolTable.BackslashUtil.getQNameWithDifferentLocal(BackslashUtil.java:62)[axis-wsdl2java]atorg.apache.axis.wsdl.symbolTable.BackslashUtil.getQNameWithBackslashless Local(BackslashUtil.java:39)[axis-wsdl2java]atorg.apache.axis.wsdl.symbolTable.SymbolTable.populateServices(SymbolTable.java:3078)[axis-wsdl2java]atorg.apache.axis.wsdl.symbolTable.SymbolTable.populate (SymbolTable.java:745)[axis-wsdl2java]atorg.apache.axis.wsdl.symbolTable.SymbolTable.add(SymbolTable.java:543)[axis-wsdl2java]atorg.apache.axis.wsdl.symbolTable.SymbolTable.populate(SymbolTable.java :518)[axis-wsdl2java]atorg.apache.axis.wsdl.symbolTable.SymbolTable.populate(SymbolTable.java:495)[axis-wsdl2java]atorg.apache.axis.wsdl.gen.Parser$WSDLRunnable.run(Parser.java:361) [axis-wsdl2java]at java.lang.Thread.run(Thread.java:534)Any help would be greatly appreciatedThanksJeremy-- -- Jaya
Re: Piccolo XML Parser and Axis
or you could just use XMLBeans which uses Piccolo. There were some posts a while back about how to use XMLBEans as your xml bindings.On 12/15/05, Thorsten Jungblut [EMAIL PROTECTED] wrote:Hi, is there any known issue when using Piccolo as XML parser on the serverside?I'm using tomcat5.0, i tried out patch level 28 and 30, Axis 1.1 andPiccolo 1.04.I keep getting an error:faultString: org.xml.sax.SAXParseException: Unexpected end of file afternullWhen using Xerces, everything works.Best regardsThorsten
Re: AXIS client, applet, socket:// problem
I think I found the cause: the usage of Socket class (sock = new
Socket(host, port); in DefaultSocketFactory.java).
I tried to instantiate a socket in a similar manner in an applet
(without using axis) and the message 'network: Connecting
socket://www.delsyne.ro:80 with proxy=DIRECT" appeared again in the
java console. And it happened only by instantiating the socket
object... So, it seems axis generates this side-effect by instantiating
the socket directly.
I guess I'm stuck between the applet, the axis' socket and the client's
(unavailable) socket proxy. Is it a bad idea to use axis in an applet
after all? I guess people used it before, the only different situation
I can see is that socket proxy of our client...
Best regards,
George.
George Mardale wrote:
Hi,
thanks a lot for your feedback...
In order to make things easier to understand, here is an excerpt from
the java console with axis log level set to debug:
- org.apache.axis.i18n.resource::handleGetObject(setMsgForm)
- org.apache.axis.i18n.resource::handleGetObject(setMsgForm)
- Setting current message form to: FORM_OPTIMIZED (currentMessage is
now org.apache.axis.utils.ByteArray)
- Setting current message form to: FORM_OPTIMIZED (currentMessage is
now org.apache.axis.utils.ByteArray)
- Exit: SOAPPart::saveChanges(): [EMAIL PROTECTED]
- Exit: SOAPPart::saveChanges(): [EMAIL PROTECTED]
- Enter: SOAPPart::saveChanges
- Enter: SOAPPart::saveChanges
- Enter: SOAPPart::saveChanges
- Enter: SOAPPart::saveChanges
network: Connecting socket://www.delsyne.ro:80 with proxy=DIRECT
- org.apache.axis.i18n.resource::handleGetObject(createdHTTP00)
- org.apache.axis.i18n.resource::handleGetObject(createdHTTP00)
- Created an insecure HTTP connection
- Created an insecure HTTP connection
- org.apache.axis.i18n.resource::handleGetObject(xmlSent00)
- org.apache.axis.i18n.resource::handleGetObject(xmlSent00)
- XML sent:
- XML sent:
- ---
- ---
- Enter: SOAPPart::saveChanges
- Enter: SOAPPart::saveChanges
- POST /axis/Calculator.jws HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related,
text/*
.
I couldn't locate an explicit socket usage in the axis implementation,
but the socket:// seems to appear "in the proximity" of
HttpSender.getSocket() method call in HttpSender.writeToSocket(). It
could be a side-effect of signed jars/applets, as you stated... I will
check the other mailing list...
Thanks again for your advice,
George.
iksrazal wrote:
I can't help much but can offer some advice.
I've done a fair amount of socket programming and never even seen a prefix '
socket:// ' . Signed jars from an applet make it even more of a specialized
question. I suggest posting the question on a general java forum like
comp.lang.java.programmer . Place 'signed jars' 'applet' and ' socket:// ' in
the message and your likely to get a response. That might be able to narrow
your question down to where it becomes more of a general axis question.
Just my .02 cents.
iksrazal
Em Quinta 15 Dezembro 2005 09:21, o George Mardale escreveu:
Hi guys,
I don't want to offend anybody, but is this a stupid question or a hard
one? I didn't receive any replies and I must say I googled a few hours
searching for an answer, so it might be a hard question (?).
Best regards,
George.
George Mardale wrote:
Hi everybody,
I use axis1.3 and JDK1.5.0 to develop an applet that calls a
webservice (the webservice is very simple, it calculates the sum of 2
integers and returns it to the client) and handles its response. The
applet and all required jars are signed, they are downloaded on the
client side without problems.
When the applet invokes the webservice, using the following method call:
Integer ret = (Integer) call.invoke( new Object[] { i1, i2 } );
the following log messages appear in the browser's java console:
security: Loading certificates from Deployment session certificate
store
security: Loaded certificates from Deployment session certificate
store
security: Loading certificates from Internet Explorer
TrustedPublisher certificate store
security: Loaded certificates from Internet Explorer
TrustedPublisher certificate store
security: Checking if certificate is in Deployment permanent
certificate store
network: Connecting socket://www.delsyne.ro:80 with proxy=DIRECT
(- this connection causes me problems)
network: Connecting
http://www.delsyne.ro/evsMonitoring/intBeanInfo.class with proxy=HTTP
@ delsyne.ro/82.79.170.47:3128
network: Connecting
http://www.delsyne.ro/evsMonitoring/intBeanInfo.class with cookie
"Bugzilla_login=2; Bugzilla_logincookie=2; DEFAULTFORMAT=specific"
The problem with the "socket://" call is that in some environments
users are behind a proxy, which only accepts "http://" requests. Thus,
all calls to "socket://...
Re: axis2 impressions
I also have not found the experience of working with web services and apache axis a pleasurable one. I'm glad my project has been put on hold because the learning curve is so steep. Here's a few issues I have had: 1. Initially I started out using the Sun reference implementation and installed the extensions to my Sun ONE instance. This had performance and memory implications on the server. I switched to Apache Axis instead. 2. The whole arena of web services is compliated because of so many changes over so little time. I found a few tutorials on the net but if they were in 2002 you never knew if it was the right way to do things now. 3. The Apache axis docs were pretty bad. Its not geared towards learning the way to use axis, more a reference. I had no idea how to add axis to an existing application. I did it in the end becasue some helpful guy had made available a minimal app that you could use to start from on his blog (why doesn't the main site provide this?). The 1.3 download has docs for 1.2. 4. The touted tool support is a double-edged sword because you need to know what they are doing to enable debugging but you don't have enough knowledge at a low level. For instance, when i tried the upgrade from 1.2--1.3 by replacing the axis jar, my ant tasks failed (wsdl2java/java2wsdl) . I had no idea where to begin to solve this. Overall I'd say that dealing with the underlying servlet code and xml libraries would have been easier to use and easier to understand. I feel that Apache Axis and maybe even web services in general is over-engineered and more compilcated than the alternative implementation (dealing with servlets and xml). Implementation A 1. code a servlet to transfer xml. 2. Use something like JDOM to create/read/update the xml. 3. Use web container functionality such as session timeout, user management and ssl. Done it before many times Implementation B 1. Learn Apache Axis and add to your app. 2. Work out how to use and intergrate the tools into your build process. 3. Learn the myriad ways to do everything such as security and transfer modes and rpc and filters and exceptions etcetcetc(and then watch them change). A is easier when you have to get the job done. Perhaps I'm missing the point. Its when the functionality you need is much more advanced that it pays back the approach. However, if it can't satisfy simple requirements then i think its a failure becuase no-one is going to jump into the complicated stuff when they are first starting out. Sorry for the rant but i thought I should give some feedback. Rakesh Srinath Perera wrote: Hi Todd; Are referring to Call/MEPClient API or Generated Stubs. We do not force you to use the OM* API unless you need XML level support. You can use the generated Stubs and Client s and work with out seen a OMElement at all. Q) are you happy with Axis1.x API? what you had there and missing at Axis2 If it is good architecturally .. we can fix the client API If only you can provide constructive comments. Remember lot of developers has different opinions about it .. some quite opposite. Tell us 1) Exactly in detail what are the problems? 2) What your expected scenarios .. with example may be 3) Suggestions to how to fix current API If you do, we can discuss and improve Axis2, if you arguments are reasonable we love to make the fixes. On the other hand if the Xfire serve you better please go for it. If you comment please be constructive ..random opinions do not help anybody!! Thanks Srinath On 12/15/05, Todd Orr [EMAIL PROTECTED] wrote: The more I learn about Axis2, the less appealing it is. It seems to be giant leap backwards. Why is coding using OMElement (and the other OM... objects) a better approach than deploying a POJO? This is a huge pain. Not to mention the deployment issues that I've already run into. Based on the documentation I feel as though Axis2 is a step forward architecturally, but extremely weak in user friendliness. For this reason I've been finding myself more interested in XFire. It has many features of Axis2, yet is extremely easy to create Web services with. Why would the Axis2 team go in this anti-productivity direction?
Hiding Axis implementation code
Hi All: I'm currently using Axis 1.2.1 and am wondering why the wsdl2java tool does not generate interfaces along with the beans it creates? Is there a mechanism to make the generated beans implement a particular interface? I'm really trying to find the proper way to hide axis from my webService code. My thought was that if I could work with interface's for my beans, I could easily switch out axis for another framework if desired. Any thoughts would be welcome. Gregg
Re: Hiding Axis implementation code
Hello Gregg, I use the --helperGen option to prevent Axis metadata being generated in my beans. Also, I use -T1.3 to use the JAX-RPC1.1 mapping (for instance, to map xsd:unsignedShort - int, not org.apache.axis.types.UnsignedShort) -H, --helperGen emits separate Helper classes for meta data -T, --typeMappingVersion argument (cryptic description but 1.3 follows JAX-RPC1.1.) Regards, Dies McMullin, Gregg E. wrote: Hi All: I'm currently using Axis 1.2.1 and am wondering why the wsdl2java tool does not generate interfaces along with the beans it creates? Is there a mechanism to make the generated beans implement a particular interface? I'm really trying to find the proper way to hide axis from my webService code. My thought was that if I could work with interface's for my beans, I could easily switch out axis for another framework if desired. Any thoughts would be welcome. Gregg
Re: EchoNonBlockingDualClient
NopDavanum Srinivas [EMAIL PROTECTED] wrote: Is this a IPv6 box?On 12/14/05, Alan Aguia <[EMAIL PROTECTED]>wrote: Hi Im trying to deploy the EchoNonBlockingDualClient in my sun solaris 8 server but I get this error, I dont know what its causing the problem and how to solve it. Im running axis2 using jboss and with a proxypass from apache. If I run EchoNonBlockingClient everything work fine. Alan. 2005-12-14 12:10:20,787 INFO [org.apache.axis2.engine.AxisEngine] Axis Engine Started 2005-12-14 12:10:20,787 INFO [org.apache.axis2.engine.Phase] Invoke the Handler AddressingOutHandlerwith in the Phase MessageOut 2005-12-14 12:10:20,797 INFO [org.apache.commons.httpclient.HttpMethodDirector] I/O exception caught when processing request: Connection refused 2005-12-14 12:10:20,797 INFO [org.apache.commons.httpclient.HttpMethodDirector] Retrying request 2005-12-14 12:10:20,801 INFO [org.apache.commons.httpclient.HttpMethodDirector] I/O exception caught when pr ocessing request: Connection refused 2005-12-14 12:10:20,801 INFO [org.apache.commons.httpclient.HttpMethodDirector] Retrying request 2005-12-14 12:10:20,806 INFO [org.apache.commons.httpclient.HttpMethodDirector] I/O exception caught when processing request: Connection refused 2005-12-14 12:10:20,806 INFO [org.apache.commons.httpclient.HttpMethodDirector] Retrying request Yahoo! Shopping Find Great Deals on Holiday Gifts at Yahoo! Shopping--Davanum Srinivas : http://wso2.com/blogs/ Yahoo! Shopping Find Great Deals on Holiday Gifts at Yahoo! Shopping
Re: axis2 impressions
We build with maven and have a simple goal that iterates through the project'sdependencies and copies them all into the lib folder of the axis2 webapp. Another goal removes them. This is pretty easy to do and frees you fromhaving to worry about modifying the axis2 war file.We use JBoss4 and Ant. In our environment, we would still have to alter the deployed war unless we either built axis2 each time, or un/re-packaged the war each time. This situation is less than ideal. Even if this is a headache for my release engineer and therefore is mitigated to one resource, it still pales in comparison the to developer productivity drawbacks stated. On 12/15/05, Alex Artigues [EMAIL PROTECTED] wrote: 5This new approach is incompatible with my company's build scripts. Automating the build seems to be a hassle. I do not even see a nice way to do this - explode the war, build and deploy my aar files to the exploded war, then repackage? Ugh.We build with maven and have a simple goal that iterates through the project'sdependencies and copies them all into the lib folder of the axis2 webapp.Another goal removes them.This is pretty easy to do and frees you from having to worry about modifying the axis2 war file.--Alex
Re: accessing SOAP Header values in Service Implementation
MessageContext context = MessageContext.getCurrentContext(); SOAPMessage message = context.getMessage(); SOAPHeader header = message.getSOAPHeader(); // header is essentially a DOM 'Element', you can use any of the 'Element's API // example access... Element headerElement = header.getElementsByTagName(); On 12/15/05, zze-ELSOKHON Tony RD-BIZZ-ISS [EMAIL PROTECTED] wrote: Hi, You can access the classes related to the SOAP request message through the current message context, which you can get through MessageContext's class method: getCurrentContext. For detailed information, please look at the Axis Javadoc related to the classes MessageContext, MessageElement, SOAPHeaderElement… Regards, Tony De: Nathaniel Auvil [mailto:[EMAIL PROTECTED]] Envoyé: jeudi 15 décembre 2005 15:52 À: axis-user@ws.apache.org Objet: accessing SOAP Header values in Service Implementation Can anyone point me to information on how to access a value from the SOAP Header in the Service Implementation? For example i need to get a value from the soap header in my service method.
Re: axis2 impressions
As someone who has worked alot with axis 1.x and axis2, allow me to put my 2 cents in... Em Quinta 15 Dezembro 2005 13:49, o Todd Orr escreveu: You're right. Random comments are not helpful. In general, however, Axis1 was far easier to get a working app up with. 1.I was mainly taken by surprise by the OMElement approach that is explained in the user guide's own implementation ( http://ws.apache.org/axis2/userguide.html#Web_Services_Using_Axis2). If this is a special case, then it shouldn't be the only one in the user guide. I didn't find anywhere that I could just deploy a POJO (with minimal metadata in the wsdd) as I can with Axis1. Its open-source, feel free to document it. I personally needed a WSDL2Java ant task with axis2, and once I figured it out how to do it I was invited to document it, which I did. I personally found the OMElement approach easy enough to undersatand to get started without wsdl. Digging deeper you'll find the Call interface still there. WSDD is IMHO far inferior to the services.xml / aar / hot deployment approach, and one of the reasons I moved to axis2. 1.1 Perhaps number 1 is completely wrong. If so, the documentation needs to point this out. If my experience thus far is unfair it is because the documentation is incomplete (expected early in the project) at a minimum, and from my personal experience it is misleading (unacceptable). 2. I feel as though the need to work with WSDLs directly is a failing of the implementation (whichever implementation). Ideally the situation should be that there are times in unusual circumstances that you might need to work with the WSDL directly. The majority of Web service deployments should be as simple as providing metadata via XML or annotations that handle the type of things that you would need to alter the WSDL for. It seems that Axis2 is no further away from this than Axis1 ever was. If anything it further perpetuates this anti-productive vein of thought. The documentation is rife with references and how-tos relating to WSDL2Java. This is backwards thinking and it permeates both Axis1 and 2 users/developers. I work with objects. We all, as Java developers, work with objects. Java developers are most productive when working with objects, in general. I'm not trying to start a flame war on this subject, but whenever I hear, oh you need to edit the WSDL to do this or that I cringe. It's not that I can't. It's that I shouldn't have to. If you think I'm wrong, look at ejb2 vs ejb3 in regards to the various xml files. Same story, different project. Even then, I contend that ejb deployment descriptors are easier to work with than WSDLs. WSDL is a major fact in web services development - I don't see it as a being unusual circumstances at all. The OMElement stuff allows you to avoid wsdl just like Call.invoke() can. WSDL has a lot of power behind it. It may be difficult now, but with a little effort learning it soon it won't be. If you want to work with objects, then Complex Types and WSDL should be a natural fit. Once I learned how to use java.util.List with wsdl to represent my data, along with my customs types, there was no turning back. I've actually even used EJB with WSDL together - alot. There are a lot of files to touch, buts its only hard for a few days and then its easy. Then again, wsdl is not mandatory. I actually spent my first 2 years doing web services without wsdl. When it became a requirement I cringed. After a few weeks I started to like it. 3. JRS-181 is awesome. After using XFire's implementation, I do not know if I will be able to go back to a non-annotated world. Then use XFire and be happy. I haven't got to JRS-181 - all in due time. 4. Poor out of the box support for other frameworks (eg Spring). I would like to be able to manage my Web services like any other bean in a webapp. I'm sure if I hack away I can manage to put something specific to my project together, but then there will be hundreds of homegrown implementations that no one body has knowledge of or is responsible for. Axis2 does not live in a vacuum. There's a lot of frameworks out there. It'd be nice if the project recognized and supported this idea. There is support for spring - I'm a dedicated, happy user of spring. http://marc.theaimsgroup.com/?l=axis-devm=112866697704950w=2 I personally use the ObjectFactory approach as we have an existing app. I'd like to see Spring documented but not too many people have been asking for it. 5. Weird deployment model. I guess that having a JEEish packaging scheme is a good thing. However, I've lost all the benefits of creating a war of my own for my services. I can no longer specify my own url-mappings without editing the axis2.war, which is not in my source control (and shouldn't be). This new approach is incompatible with my company's build scripts. Automating the build seems to be a hassle. I do not even see a nice way to do this
Re: axis2 impressions
Em Quinta 15 Dezembro 2005 14:11, o Todd Orr escreveu: We build with maven and have a simple goal that iterates through the project's dependencies and copies them all into the lib folder of the axis2 webapp. Another goal removes them. This is pretty easy to do and frees you from having to worry about modifying the axis2 war file. We use JBoss4 and Ant. In our environment, we would still have to alter the deployed war unless we either built axis2 each time, or un/re-packaged the war each time. This situation is less than ideal. Even if this is a headache for my release engineer and therefore is mitigated to one resource, it still pales in comparison the to developer productivity drawbacks stated. I don't get it. Got your own war? in your war ant task put another dir under WEB-INF called services. Build a jar with an aar extension and plop it in. Move the axis2.xml file into your WEB-INF. What's so hard about that? Took me an hour or so with a bigger than average project and a 1000 line build.xml . As stated - call me strange but I feel more productive with axis2. Being constructive, I'd give some hints with your build.xml if you need it. Also as stated, its just new to you. Soon it won't be if you spend a little effort. I personally feel I've gained from axis2. Give it a shot and then decide. iksrazal On 12/15/05, Alex Artigues [EMAIL PROTECTED] wrote: 5This new approach is incompatible with my company's build scripts. Automating the build seems to be a hassle. I do not even see a nice way to do this - explode the war, build and deploy my aar files to the exploded war, then repackage? Ugh. We build with maven and have a simple goal that iterates through the project's dependencies and copies them all into the lib folder of the axis2 webapp. Another goal removes them. This is pretty easy to do and frees you from having to worry about modifying the axis2 war file. --Alex
Re: axis2 impressions
Em Quinta 15 Dezembro 2005 15:14, o Nathaniel Auvil escreveu: Can you email me with how you got axis2 to work from wsdl? I have two open Jira items on this as it blows up on my wsdl. The first problem is due to schema imports. So i eliminated the schema imports and now i get a schema exception from XMLBeans. This schema works fine with Axis 1.2.1 and is valid XML according to XMLSpy. quote Its open-source, feel free to document it. I personally needed a WSDL2Java ant task with axis2, and once I figured it out how to do it I was invited to document it, which I did. I personally found the OMElement approach easy enough to undersatand to get started without wsdl. /quote We're going to need a little more info then it 'blows up' to help ;-) . First, its got to be more than just valid xml, its got to be a valid wsdl. Google for the 'free as in beer' soa editor from cape clear. The XMLBean issue I think you have is documented here: http://ws.apache.org/axis2/CodegenToolReference.html There's also a sample wsdl and code. The sample is a little rough - I've been making a transition from 'rpc encoded' to doc / lit . Nevertheless, it is a fully working sample. HTH, iksrazal
Re: Running Axis (1.3) through port other than 8080
Simon, My recommendation is to front end the web service (running on tomcat) with Apache HTTP 2.X (or even 1.X) for production purposes. thanks, dims On 12/15/05, Simon McMahon [EMAIL PROTECTED] wrote: Hi, Sorry if this is an obvious one but I couldn't find how to get Axis to work via port 80. Our firewall doesn't let anything else through. Thanks, Simon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 * This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/ received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is strictly prohibited. The information contained in this email, including any attachment sent with it, may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone collect on Australia +61 1800 198 175 or by return email. You should also delete this email, and any copies, from your computer system network and destroy any hard copies produced. If not an intended recipient of this email, you must not copy, distribute or take any action(s) that relies on it; any form of disclosure, modification, distribution and/or publication of this email is also prohibited. Although Queensland Health takes all reasonable steps to ensure this email does not contain malicious software, Queensland Health does not accept responsibility for the consequences if any person's computer inadvertently suffers any disruption to services, loss of information, harm or is infected with a virus, other malicious computer programme or code that may occur as a consequence of receiving this email. Unless stated otherwise, this email represents only the views of the sender and not the views of the Queensland Government. -- Davanum Srinivas : http://wso2.com/blogs/
Re: How to change PORT for WSDL
Thanks for your prompt reply, I have applied your suggested procedure for my wsdl, i have copied my system generated wsdl into my /WEB-INF/classes folder and replaced the localhost:8080 with myhost:80 and also specify wsdlFilemywsdlfile.wsdl/wsdlFile element under my service entry in server-config.wsdd file, it generates correct host name but wrong port 8080, while my default port is 80. can you tell me the solution for this Regards, Muhammad Iqbal cell :0092-300-9377801 From: jayachandra [EMAIL PROTECTED] Reply-To: axis-user@ws.apache.org To: axis-user@ws.apache.org Subject: Re: How to change PORT for WSDL Date: Wed, 14 Dec 2005 21:21:27 +0530 I know this is such an uncouth work around I'm suggesting, but still ;-)... A quick work around that I'd suggest is, you can always configure inside your server-config.wsdd a location from which the wsdl is served when axis is queried for, instead of auto generating it always on the fly. You could once get a system generated wsdl, fix the port info etc. and place it inside your context classpath i.e. WEB-INF/classes, lets say with the name correctWSDL.wsdl. Then inside your server-config.wsdd just add this line under the corresponding service element wsdlFile/correctWSDL.wsdl/wsdlFile And everytime when clients query your service with ?wsdl, they get this correctWSDL.wsdl retured. HTH, Jaya On 12/13/05, MUHAMMAD IQBAL [EMAIL PROTECTED] wrote: i have a wraper style web service developed in Apache Axis1.2.1, but when i deploy it and try to access its wsdl, the URL for my service's WSDL has included port 8080 but my tomcat is running on port 80, can any one tell me that, how to change the port for my service's WSDL that auto generated by Axis? thnaks in advance. Regards, Muhammad Iqbal -- -- Jaya
Problem parsing/retrieving information from SOAPBody in a handler
Hi!
I really hope someone can provide some insight on this as It's been driving
me crazy for a while. Short story; I can't seem to be able to retrieve the
elements of a SOAPBody from my BasicHandler.
I'm writing ha handler that works on a response message from a LOGIN
service.
The task of the handler is to store an association between the returned
SessionID (Given from my LOGIN service) with the actual HTTP Session.
Client will later send the Session ID in the SOAP Header, and its
value get compared to the one associated with the HTTP Session.
It's declared like this in my deploy.wssd.
responseFlow
handler name=StoreSession
type=java:com.product.service.webservice.StoreSession /
/responseFlow
The Outgoiung SOAP Message looks like this ;
?xml version=1.0 encoding=utf-8?
soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
soapenv:Body
LoginResponse
xmlns=http://schemas.company.com/cai3g1.0/2004/01/22/;
sessionId11346898949530991623220/sessionId
baseSequenceId1134689894953/baseSequenceId
/LoginResponse
/soapenv:Body
/soapenv:Envelope
My handler code looks like this. It is invoked, after the Pivot, but the
results are bizarre. When using the method getChildElements() in SOAPElement
to retrieve the content of the soap Body, the sessionId and baseSequenceId
are nowhere to be found (!)
Instead it seems that the object hiearachy looks like this ;
SOAPBody (1 child)
| - LoginResponse (has 1 child)
- LoginResponse (has 0 children)
---8 CODE SNIPPET -- 8 --
Looking at my handler code ;
final SOAPPart sp = messageContext.getMessage().getSOAPPart();
final SOAPEnvelope spEnvelope = sp.getEnvelope();
final SOAPBody spBody = messageContext.getMessage().getSOAPBody();
Iterator i = spBody.getChildElements();
if (i.hasNext())
{
log.debug(SOAPBody Element has child elements...);
}
SOAPBodyElement loginResponseElement = (SOAPBodyElement) i.next();
log.debug(First Child of SOAPBody should be LoginResponse. It is +
loginResponseElement.getLocalName());
i = loginResponseElement.getChildElements();
SOAPElement element = (SOAPElement) i.next();
log.debug(First Child of loginResponse element should be SessionID, it is
not! It is : + element.getLocalName());
---8 CODE SNIPPET ENDS -- 8 --
Output the following debug log
- SOAPBody Element has child elements...
- First Child of SOAPBody should be LoginResponse. It is LoginResponse
- First Child of loginResponse element should be SessionID, it is not! It is
: LoginRespons
Am I Missing something very obvious here ? Bug ?
Best regards, any help will be very welcome !!
glenn richard bech
Stub problem trying to upgrade from Axis2 0.92 to Axis2 0.93
I have been using Axis2 0.92 to access a .Net web service from Java.
Today I tried to switch to Axis2 0.93. I regenerated all of the stubs using
the 0.93 WSDL2Java, and put the Asix2 0.93 libraries on my classpath, but got
the following error
when I tried a test:
org.apache.axis2.AxisFault: Server did not recognize the value of HTTP Header
SOAPAction: .
at
org.apache.axis2.client.InOutMEPClient.invokeBlocking(InOutMEPClient.java:174)
at codegen.TPServiceSoapStub.GetScrollRate(TPServiceSoapStub.java:330)
at AxisTest.makeCall(AxisTest.java:71)
at AxisTest.main(AxisTest.java:13)
The WSDL for GetScrollRate is
wsdl:operation name=GetScrollRate
soap:operation soapAction=http://tourplan.com/engine/GetScrollRate;
style=document /
wsdl:input
soap:body use=literal /
/wsdl:input
wsdl:output
soap:body use=literal /
/wsdl:output
/wsdl:operation
I've appended the two stubs below. The 0.92 stub includes the code
_call.setSoapAction(http://tourplan.com/engine/GetScrollRate;);
which seems to be what sets the soap action (the error for 0.93 seems to be that
the soap action isn't set). The only code related to the soap action in the
0.93 stub is
if(_clientOptions.getSoapAction() == null) {
}
It seems that the body of the if statment (which should presumably set the soap
action) is missing. Is there a bug in how 0.93 stubs are generated, or
have I made a mistake in setting up Axis 2 0.93?
Thanks, Paul.
Axis2 0.93 stub
---
public codegen.databinding.com.tourplan.GetScrollRateResponseDocument
GetScrollRate(
codegen.databinding.com.tourplan.GetScrollRateDocument param28) throws
java.rmi.RemoteException{
org.apache.axis2.client.Call _call = new
org.apache.axis2.client.Call(_serviceContext);
_call.setClientOptions(_clientOptions);
org.apache.axis2.context.MessageContext _messageContext =
getMessageContext();
if(_clientOptions.getSoapAction() == null) {
}
if(_clientOptions.getAction() == null) {
}
//set the properties
populateModules(_call);
org.apache.axis2.soap.SOAPEnvelope env = null;
env = createEnvelope();
//Style is Doc.
setValueDoc(env,codegen.databinding.TPServiceSoapGetScrollRateDatabindingSupporter.toOM(param28));
_messageContext.setEnvelope(env);
//set the exception throwing status
_call.getClientOptions().setExceptionToBeThrownOnSOAPFault(true);
org.apache.axis2.context.MessageContext _returnMessageContext =
_call.invokeBlocking(_operations[4], _messageContext);
org.apache.axis2.soap.SOAPEnvelope _returnEnv =
_returnMessageContext.getEnvelope();
java.lang.Object object =
codegen.databinding.TPServiceSoapGetScrollRateDatabindingSupporter.fromOM(getElement(_returnEnv,doc),codegen.databinding.com.tourplan.GetScrollRateResponseDocument.class);
return
(codegen.databinding.com.tourplan.GetScrollRateResponseDocument)object;
}
Axis2 0.92 stub
---
public codegen.databinding.com.tourplan.GetScrollRateResponseDocument
GetScrollRate(
codegen.databinding.com.tourplan.GetScrollRateDocument param28) throws
java.rmi.RemoteException{
org.apache.axis2.clientapi.Call _call = new
org.apache.axis2.clientapi.Call(_serviceContext);
_call.setTransportInfo(this.senderTransport,this.listenerTransport,this.useSeparateListener);
_call.setDoREST(this.doRest);
org.apache.axis2.context.MessageContext _messageContext =
getMessageContext();
_call.setTo(this.toEPR);
_call.setSoapAction(http://tourplan.com/engine/GetScrollRate;);
//set the properties
populateProperties(_call);
org.apache.axis2.soap.SOAPEnvelope env = null;
env = createEnvelope();
//Style is Doc.
setValueDoc(env,codegen.databinding.TPServiceSoapGetScrollRateDatabindingSupporter.toOM(param28));
_messageContext.setEnvelope(env);
//set the exception throwing status
_call.setExceptionToBeThrownOnSOAPFault(true);
org.apache.axis2.context.MessageContext _returnMessageContext =
_call.invokeBlocking(_operations[4], _messageContext);
org.apache.axis2.soap.SOAPEnvelope _returnEnv =
_returnMessageContext.getEnvelope();
java.lang.Object object =
Re: axis2 impressions
Dear Todd, Thank you for the feedback we do appreciate it so pls keep it comming. I have included some comments regarding some things with significance that you have pointed out 1) The reason for having the OMElement instead of the POJO is axis2 engine is based on the StaX API. At least for me OM looks nicer than meddling with the StAX events. So OMElement has very good advantages (very much beyond simple easyness) than you might comprehend. Problem with POJO is that it cannot be serialisable directly to the stax and we don't have a such typemapping mechanism now. There are ways to fix this if you can write a Serialiser that push stax events. 1.1) Bad documentation!!! Well it isn't the best but it gives an understanding for many. Help with documentation is always warmly welcomed. 2) Well Java2WSDL tool is on the way. Understand this we haven't reach the Version 1.0 mark yet. So we are not calling this a finish product and there are things to finish. 3)I personally would like to get the annotations but there are other prorities in the SOAP processing model that we need to fill up. The expectations of the different users of Axis2 is different, but we try to prioratise the most general user requirement. Thanks Chathura P.S. Btw, I am (as a an Axis2 developper) not interested in promisses that you are going to keep in a hypothedical opensource product that you are gonna release. On 12/15/05, Todd Orr [EMAIL PROTECTED] wrote: Its open-source, feel free to document it. I've been having trouble even being able to come up with an implementation to prove that it can be done. I cannot sell my boss on RD to hack through the internals to figure out exactly what is happening. I've only been allocated time to compare and contrast alternative implementations. All frameworks should understand that their end users (me) are not always in the position to do the research and documentation for them. If I had that kind of time, I'd start my own open source projects. I've got lots of things I want to do for the community too. I just have a demanding job. I know that the Axis team also have jobs too. The difference is that I am not open sourcing a project for general consumption. It's a much appreciated effort - don't get me wrong. Its open-source, feel free to document it. I personally needed a WSDL2Java ant task with axis2, and once I figured it out how to do it I was invited to document it, which I did. I personally found the OMElement approach easy enough to undersatand to get started without wsdl. Digging deeper you'll find the Call interface still there. The call interface is not really what I'm talking about. I prefer writing a POJO that has no knowledge that it is a Web service endpoint. I have done this with Axis1. WSDD is IMHO far inferior to the services.xml / aar / hot deployment approach, and one of the reasons I moved to axis2. Agreed. ...I actually spent my first 2 years doing web services without wsdl. When it became a requirement I cringed. After a few weeks I started to like it. I have nothing against WSDL. I work with them now in Axis1. The problem is not one of expertise or developer knowledge. It is an issue of necessity and developer ramp up. There is very little (any?) information in a WSDL that couldn't be maintained in a more straight forward metadata language (annotations, service.xml?). The best Web service implementation should alleviate this headache. It's not a matter of how hard or easy it is. It just shouldn't be there if the framework went the extra mile for the developer. Then use XFire and be happy. I haven't got to JRS-181 - all in due time. Understandable. http://marc.theaimsgroup.com/?l=axis-devm=112866697704950w=2 I've already attempted to use this. Besides the fact that it doesn't address my issue with homegrown implementations, it doesn't work. I've deployed it to my axis2 installation via the Web interface and in is faulty. I would say novel and clever instead of weird. I might say divergent from known standards and applications. I never used AdminClient anyhow. I dropped the axis jars into my webapp, configured my web.xml and was off and running. All the while my company's build scripts worked flawlessly. That's expected, standards based behavior. You could start by documenting alternatives to OMElement - my guess is that if its good it'll get accepted. Just file a jira when you're ready. Honestly, I want to help out. In an ideal world I wouldn't have to go to work all day and participate in my family at night. It's just not feasible. If my company ever releases a software product for general consumption, I will work to ensure that the complaints I have risen here do not happen in regards to my product. That's a promise I can keep. On 12/15/05, iksrazal [EMAIL PROTECTED] wrote: As someone who has worked alot with axis 1.x and axis2, allow me to put my 2 cents in... Em
proxyservice and documentation.
We have a load balancer in front of the cluster where web service resides. We need to make the service available to axis clients. I realize, proxy service is one of the solutions. Came across one example in "axis-1_3\samples\proxy". Any documentation on that. Any other resource, where I could see some details about accessing Web Service which is behind the load balancer.Vipul
