[starksm64]

Where is an rmi/http ejb3 testcase that illustrates this problem? With our current service oriented dependcies, ejb3 depends on remoting which if an http connector exists, needs to depend on the war deployer. Hiding the remoting dependency under urls is still a remoting dependency, if only on a transport resolver service.

[tom.elrod]

There is no rmi/http ejb3 testcase that I know of. Are there any ejb3 testcases that run as part of the testsuite (which exercises running ejb3 within JBossAS)? I didn't see any in the 4.0 branch.

Don't know why you keep saying that using http remoting transport requires war file. There are two distinct transports that involve web requests. The first is the remoting http invoker, which requires the tomcat jars be on remoting's classpath (no war file is involved). Then there is the servlet invoker, which requires that the servlet-invoker.war is deployed in the web container (this transport does not directly require tomcat jars).

It is a requirement for the http server invoker to work within remoting that the tomcat jars are present on the classpath. However, remoting does not care how this requirement is met. It would appear that the only way this requirement can met if using http transport within ejb3 container would be to include the tomcat jars in the lib directory. Maybe someone else knows of a better way?

[starksm64]

There is no rmi/http ejb3 testcase that I know of. Are there any ejb3 testcases that run as part of the testsuite (which exercises running ejb3 within JBossAS)? I didn't see any in the 4.0 branch.

The ejb3 tests are in the ejb3 module.

Don't know why you keep saying that using http remoting transport requires war file. There are two distinct transports that involve web requests. The first is the remoting http invoker, which requires the tomcat jars be on remoting's classpath (no war file is involved). Then there is the servlet invoker, which requires that the servlet-invoker.war is deployed in the web container (this transport does not directly require tomcat jars).

Then explain the functional difference between these. The non-war one can't possibly depend on all of the tomcat jars so explain the details. Putting jars into the lib directory typically restricts the ability to redeploy the service depedning on statics caching types across deployments. Without understand what from tomcat is being used I don't know what the best deployment is.

[tom.elrod]

Servlet invoker doc - http://labs.jboss.com/portal/jbossremoting/docs/guide/ch04.html#d0e858

HTTP invoker doc - http://labs.jboss.com/portal/jbossremoting/docs/guide/ch04.html#d0e706

The HTTP server invoker (see org.jboss.remoting.transport.coyote.CoyoteInvoker) needs classes that live in tomcat-coyote.jar and tomcat-util.jar (are actually declared in as imports). If the tcnative-1 lib is found, the CoyoteInvoker will use the APR base protocol handler (which requires tomcat-apr.jar). If it is not found on the path (which by default it would not, as requires user to manually put it there), the CoyoteInvoker will use the java based HTTP protocol handler (which requires tomcat-http.jar).

[starksm64]

It seems to me that the http invoker and tomcat are mutually exclusive services. Why do I want both configured? Either the http invoker is configured or tomcat+servlet invoker is configured.

[tom.elrod]

I would agree that is makes sense to use one or the other (and not both). Does not mean that someone won't try it.

[starksm64]

So the current integration needs to be based on the servlet invoker. Its a future issue to consider if the tomcat sar itself needs to be broken up to allow use of the transport outside of the web container.

[tom.elrod]

Sounds good to me. Along those lines, have any suggestions for http://jira.jboss.com/jira/browse/JBREM-139?

[starksm64]

The servlet invoker seems more of an integration service that should be released seperately from the remoting core and integrated into jbossas with associated tests.

[tom.elrod]

Seems to me should be handled at the invoker level (i.e. UnifiedInvoker) and use a service like the org.jboss.web.WebService we currently have. The WebService actually looks fairly good to me to what is needed (i.e. downloading classes). Maybe add another configuration attribute for what type of class files can be downloaded (i.e. "com.acme.domain.*") and should be sufficient?

Also, where is the client code for downloading classes from the WebService?