-
1. Re: securing servlet invoker?
tom.elrod Jul 12, 2006 1:32 PM (in response to mazz)The problem with the servlet invoker on the server side is that because it is deployed in a web container, remoting does not know all the configuration associated (such as ssl). Therefore, just assume lowest common denominator, which is plain old http (non ssl). This is really only important for discovery since locator url published in detection message would be something like (servlet://myhost:8080/bla).
However, if are not using remoting discovery and can explicitly set the locator url on the client, then can use 'http' or 'https' as on the client side will be using the HTTPClientInvoker (or HTTPSClientInvoker) regardless of if is talking to http server invoker or servlet server invoker (which would be running within a web container). The HTTP(S)ClientInvoker has no implicit knowledge of what implementation it is sending and receiving http requests to/responses from. -
2. Re: securing servlet invoker?
tom.elrod Jul 12, 2006 1:48 PM (in response to mazz)Have added a jira issue to include a sslservlet transport.
http://jira.jboss.com/jira/browse/JBREM-539 -
3. Re: securing servlet invoker?
mazz Jul 12, 2006 2:23 PM (in response to mazz)Because this servlet transport (and the new sslservlet one) will really be using HTTP/HTTPS transport under the covers, I'm assuming I will need all the extra jars that are required for that (I haven't played with the http/https transport yet - isn't there some tomcat jars that are required for those to work?)
-
4. Re: securing servlet invoker?
tom.elrod Jul 12, 2006 2:27 PM (in response to mazz)Only need the tomcat jars for the server side. The client side (HTTP(S)ClientInvoker) should not need any extra jars.