access to tomcat jars for remoting

[tom.elrod]

This post is in regards to jira issue - http://jira.jboss.com/jira/browse/JBAS-2766.

Since the change of remoting http server invoker to use the tomcat connectors, there has been a requirement for the following tomcat jars to be accessible to remoting when running a remoting server using the http transport:

tomcat-apr.jar
tomcat-coyote.jar
tomcat-http.jar
tomcat-util.jar

This becomes a problem when running remoting within JBossAS. Although these jars are available within deploy/jbossweb-tomcat55.sar, they can not be seen by other services, such as the UnifiedInvoker (which uses remoting). So, if configure JBossAS to deploy a remoting Connector with a http transport and a UnifiedInvoker using that Connector, will get errors saying it can not see the tomcat classes it needs. This can be fixed by just putting these jars in the lib directory, but would rather figure out a way to make it so don't have multiple copies of the same jars.

To reproduce the current problem, replace the jboss-service.xml and the standardjboss.xml files in the default/conf directory with the ones attached to jira issue and start jboss (using the latest build from 4.0 branch). The error is:

2006-04-13 00:59:39,986 DEBUG [org.jboss.system.ServiceController] Creating service jboss.remoting:service=Connector,transport=http
2006-04-13 00:59:40,006 WARN [org.jboss.system.ServiceController] Problem creating service jboss.remoting:service=Connector,transport=http
java.lang.ClassNotFoundException: org.jboss.remoting.transport.coyote.CoyoteInvoker
 at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:82)
 at org.jboss.remoting.InvokerRegistry.loadServerInvoker(InvokerRegistry.java:372)
 at org.jboss.remoting.InvokerRegistry.createServerInvoker(InvokerRegistry.java:431)
 at org.jboss.remoting.transport.Connector.init(Connector.java:388)
 at org.jboss.remoting.transport.Connector.create(Connector.java:745)

[starksm64]

Remoting cannot be deployed this way. The depends on jboss.remoting:service=Connector,transport=http from the conf/jboss-service.xml is backwards. It should be that the http invoker depends on the remoting core. Why does this dependency exist?

[tom.elrod]

Not sure I understand. In jboss-service.xml, jboss:service=invoker,type=unified depends on jboss.remoting:service=Connector,transport=http (so unified invoker depends on remoting connector).

Are you saying unified invoker and the remoting connector should not be defined in jboss-service.xml?

[starksm64]

The jboss.remoting:service=Connector,transport=http should not be since its unusable without its associated war, correct? The legacy http invoker is deployed as a sar with a nested war for this reason.

[tom.elrod]

ok, understand now. So the http transport, which depends on tomcat jars, is pure http server and does not require war (or web container). It is puer standalone. The servlet transport does require the war and a web container (but not tomcat jars directly).

[tom.elrod]

Guess best way to put it is depends structure is:

unifiedinvoker --> remoting(http) --> tomat jars

Problem is tomcat jars are there, just within a sar, so config/jboss-service.xml is just being loaded before the tomcat sar.

One way to make this work, is to leave the UnifiedInvoker declaration in the jboss-service.xml, but move the Connector config to a separate remoting-service.xml that lives in the delopy directory. This will work, but then makes somewhat difficult to follow from config standpoint (meaning unified invoker is going to depend on a service that lives in another service file). The other option is to just document that if want http remoting trnansport, will have to do above mentioned manually (but probably even more difficult for user, but more of an edge case than the default of using socket transport).

[starksm64]

I don't want anything different than what I have to do with the installer, so inclusion of anything in jboss-service.xml that has jars outside of the lib directory won't work. Anything requiring editing of files is bad. Why even have anything in the conf/jboss-service.xml? Deploy the unified invoker as a sar in deploy.

[tom.elrod]

Using a unified invoker sar will work (and is probalby best option all around). Assume will be ok to *not* include the tomcat jars within the sar, was would expect them in the tomcat sar, or is that a bad assumption to make?

Also think this would be good to make the same changes in HEAD so uses a sar instead of the jboss-service.xml, which is is today.

[starksm64]

Right, its not ok to pull in the jars from other services. We need our services to be canonical deployments with proper dependencies so they can be used in the installer, testsuite configs and default build. Yes, update head to pull the invokers out of jboss-service.xml.

[tom.elrod]

Ok, so if I read it correctly, the unifiedinvoker.sar should include all the tomcat jars neeed by the remoting http transport.

Also, just so is known, the 2.2.0 (Bluto) release of remoting this summer will have all of the implementations broken out into different build artifacts, so will have core remoting api in one binary, then if want a particular transport, it will have its own binaries as well. This should make this whole process easier in that won't have to have a bloated unifiedinvoker.sar with all the transports' thirdparty libs bundled by default.

[starksm64]

Negative on the tomcat jars. Canonical means that the service only provides the jars it sources. The only place tomcat jars should exist is in the tomcat sar.

[tom.elrod]

ok. just read

Right, its not ok to pull in the jars from other services

as not ok to link with them, so would need to be bundled. All is clear now. Thanks.

[tom.elrod]

One other problem Dimitris just alerted me to, which is for ejb3 deployer. It starts before tomcat sar, so it is going to have the same problem (with our without unifiedinvoker.sar being there).

[bill.burke]

ejb3 does not care about the remoting transport. The way it works is by URL string. It does no communication with the jboss remoting layer. The JBoss remoting layer is responsible for forwarding requests to the EJB3 handler.

So, what I'm saying is that so what if the deployer is deployed before tomcat?

[tom.elrod]

If you set the Connector within default/deploy/ejb3.deployer/META-INF/jboss-service.xml to use http transport, then start the server, it will fail (due to not being able to find classes that live within the tomcat jars). For example, change Connector config to:

 <mbean code="org.jboss.remoting.transport.Connector"
 xmbean-dd="org/jboss/remoting/transport/Connector.xml"
 name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3">
 <depends>jboss.aop:service=AspectDeployer</depends>
 <attribute name="InvokerLocator">http://localhost:8888</attribute>
 <attribute name="Configuration">
 <config>
 <handlers>
 <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>
 </handlers>
 </config>
 </attribute>
 </mbean>

So, there has to be some way to provide visibility to these jars when the ejb3 deployer service starts.