Re: AXIS client, applet, socket:// problem

[George Mardale]

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://... 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.