The HTTP RMI tunning is the shits. Firstly there is no option to go with https without getting really ugly. Secondly, the whole cgi-script or servlet which then calls the local rmi listener generates two network calls for lookup. Since jetty is running in the container the servlet lookup should be a local JNDI lookup.
If you read Holger's web site (http://smartcc.sourceforge.net) he is trying to cleanup EJB transport issues when firwalls are in the way. I hope somebody with more knowledge than me steps up to the plate. I for 1 will be using this stuff.. On Fri, 2002-06-21 at 08:36, Bill Burke wrote: > JDK already has built in RMI HTTP tunneling. Why would we need this > transport? > > Here's directions: > > > http://www.dmh2000.com/ApacheTomcatRMI.htm > > Bill > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > Holger Engels > > Sent: Friday, June 21, 2002 5:00 AM > > To: [EMAIL PROTECTED] > > Subject: [JBoss-dev] http transport > > > > > > > > I try to understand, how a http transport can be implemented within jboss > > .. so what do I need? > > > > > > on the server side: > > > > o a connector servlet / extra http deamon, that accepts invocations > > embedded in http posts. the result of a home invocation is a handle. > > subsequent invocations (remote interface) contain the handle to identify > > the target ejb. the servlet is completely stateless. > > o an mbean service, that manages the servlet / http deamon > > > > > > on the client: > > > > o some interceptor (the last one in the chain), that marshalls the > > invocation as an http post request and demarshalls results / throwables. > > I call it the 'Transport' > > o is a special handle implementation required? > > o usertransaction handling is transparent (part of Invocation)? > > > > > > configuration: > > > > o it's the server's job to provide the connector servlet. the servlet > > doesn't need to be configured. the invocations carry all the information > > that is required to perform home-/ remote-invocations. > > > > o the client will do a lookup first (coded name, declared in the > > application-client descriptor). it then gets a dynamic proxy passing on > > the java style invocation to the invocation handler. the invocation > > handler feeds the invocation into the interceptor chain. this chain has > > to be configured somehow (during deployment of the application-client > > jar). > > > > o afaik there's no application client deployment at the moment and the > > client side interceptors are configured from the server, right? > > > > > > so what makes up the whole interceptor chain? we distinguish: > > > > o client side interceptors > > o server side interceptors (synchronization, pooling / caching, security) > > o symmetric interceptors (encryption / decryption for instance) > > > > the overall configuration of the (ordered) interceptor chain is made of > > component aspects and reference aspects. transport is just another aspect > > of the reference. > > > > > > authentication: > > > > in the smartcc, using the http transport requires a http login module > > (basic/digest auth) to be configured. the authentication task is > > performed > > by the servlet container. the container cares about setting up the > > security association. > > > > > > dain asked for an http plugin for jndi. my question: why do I need the > > server side's jndi content on the client if I don't lookup homes? what > > does a java client need beside what's configured in the > > application client > > descriptor. what am i missing? > > > > holger > > > > > > > > ------------------------------------------------------- > > Sponsored by: > > ThinkGeek at http://www.ThinkGeek.com/ > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ------------------------------------------------------- > Sponsored by: > ThinkGeek at http://www.ThinkGeek.com/ > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ------------------------------------------------------- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
