+1
Sanjiva Weerawarana wrote:
> I'd like to nominate Scott for committer status. He has been
> one of the most consistent contributors to this project, but
> for some reason we neglected to make him a committer. Scott
> is also a frequest contributor to soap-user.
>
> Please vote with your +1!
>
I got this working in Iplanet Enterprise 6.0 with jdk1.4.0, I can
send the notes on that if you care, but didnt try with tomcat. I'll
post my notes for that to this list anyways later this week. I can
tell you it was a big help to have the client's certificate (client was
a java program) as a
g your method.
Scott
- Original Message -
From: "Andrew Trieger" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, April 22, 2002 13:15
Subject: Re: using SOAPContext as first argument in RPC SOAP messages
class
notworking
> sure, i'm sending this just
rintln ("Ouch, the
call failed: ");
System.out.println (" Fault
Code = " + fault.getFaultCode ());
System.out.println (" Fault
String = " + fault.getFaultString ());
} else {
Parameter result = resp.getReturnValue
();
System.out.println (r
Scott,
I did this on my OSX box, same environment as yours
except the OS, which i am now going to go try on windows but thought i'd
send the results first. I got this:
[atrieger@shadowfax workspaces]$ java HelloWorldClient http://shadowfax:8080/soap/servlet/rpcrouter
Ouch, the call failed
Vamsi,
This is the setup of the Call object my xml client
builds (and later does call.invoke())
params.addElement(new Parameter("arg", String.class,
"This is my string, given for you.", null));
call = new Call("urn:helloWorldWithArg",
"helloWorldWithArg",
Good idea, but I *think* its not even executing my method as my first
line println isnt coming out, so I'm screwed, but i might be able to
subclass rpcrouter servlet, use mine instead of theirs, catch throwable
and dump any info to stderr...
Any idea if defining my own custom fault-handler would
yeah, that is a good idea. The servlet.jar I compiled against was the same for all
tests
as I forgot to change it, which is the servlet.jar in tomcat4.0. So in theory Iplanet
could have a problem with that, but:
1. the test fails in tomcat as well as soon as I add the SOAPContext arg to the m
oh yeah, there are some great docs in the jsse. examples and stuff,
check out the jdk1.4.0 docs at java.sun.com and find the jsse specific
stuff. its not soap-specific, but enabling SSL in a java program has
nothing to do with soap, the two are really nicely separated.
Drew
When doing normal SSL communications, without authorization, i.e.
you have a webserver with ssl turned on and it has the /bla/bla/rpcrouter
servlet there, and you want to allow anyone to send it messages, then the
situation is like this:
1. the webserver has a digital certificate, a private key
I did this:
// settings for client-auth
via certs.
// Truststore
System.setProperty("javax.net.ssl.trustStore","/home/atrieger/workspaces/trieger_rootca_truststore.jks");
// missing type-setting here because
default type is jks
System.setProperty("javax.net.ssl.trustStorePa
Hello,
I've checked the bugzilla bug database and the archives
on this list and don't think this is a known problem, so I'm describing
it here to see if I'm an idiot or if its a real problem.
I soapv2.2 on linux (mandrake 8.1, kernel 2.4.x)
running in both tomcat 4.x and iplanet 6.0SP2,
12 matches
Mail list logo
