If you run up a standalone Jetty, servlts deployed within it should still be able to access EJBs deployed in JBoss, via RMI, just like any other client.
However, you will not get a number of things that come with the Jetty integration, namely local servlet/jsp-ejb calls, ENC support, hot-deploy, JBossSX integration etc...
You should think hard about what you would gain for this sacrifice and whether it is worthwhile.
We could talk about where to stick your web container all night but......
Actually this is an interesting question. I have the same problem I need to address for our production environment (tomcat/apache on the public server, jboss on a backend box).
My speculation is that the JSP/Servlets will make RMI calls to the backend, I think I just need to build an JNDI service to tell tomcat where the jboss engine is. If not JNDI, maybe something like that.
Has anyone else tried this?
oops. Posted this in the wrong thread earlier.
I got the Interest-client app to run on a different box, so I guess the procedure to run a jsp (thus tomcat) on a different server would be the same.
I had to copy the contents of the JBOSS_DIST/client dir to an accessible location so I could build the client app (I still can't find the jar that contains the javax.rmi.PortableRemoteObject class, but this works). This allowed me to compile, but not run the app. The second thing was to tweek the resource file for the client (under examples/resource, called jndi.properties). I tweeked the java.naming.provider.url from localhost to my jboss server. Now this app runs on a seperate machine. I just got to figure out how to map this to a jsp container. I'm not sure yet on how tomcat does the lookup yet.