1 2 Previous Next 24 Replies Latest reply on Feb 12, 2007 4:01 PM by tom.elrod

    access to tomcat jars for remoting


      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:


      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)

        • 1. Re: access to tomcat jars for remoting
          Scott Stark Master

          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?

          • 2. Re: access to tomcat jars for remoting

            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?

            • 3. Re: access to tomcat jars for remoting
              Scott Stark Master

              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.

              • 4. Re: access to tomcat jars for remoting

                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).

                • 5. Re: access to tomcat jars for remoting

                  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).

                  • 6. Re: access to tomcat jars for remoting
                    Scott Stark Master

                    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.

                    • 7. Re: access to tomcat jars for remoting

                      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.

                      • 8. Re: access to tomcat jars for remoting
                        Scott Stark Master

                        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.

                        • 9. Re: access to tomcat jars for remoting

                          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.

                          • 10. Re: access to tomcat jars for remoting
                            Scott Stark Master

                            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.

                            • 11. Re: access to tomcat jars for remoting

                              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.

                              • 12. Re: access to tomcat jars for remoting

                                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).

                                • 13. Re: access to tomcat jars for remoting
                                  Bill Burke Master

                                  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?

                                  • 14. Re: access to tomcat jars for remoting

                                    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"
                                     <attribute name="InvokerLocator">http://localhost:8888</attribute>
                                     <attribute name="Configuration">
                                     <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>

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

                                    1 2 Previous Next