1 2 Previous Next 15 Replies Latest reply on Mar 20, 2007 12:44 AM by tom.elrod

    jboss/remoting 2.2.0.Alpha7 not compatible with jboss5

    starksm64

      The dependency on apache-tomcat in the 2.2.0.Alpha7 version makes this incompatible with the jboss5 jbossweb-2.0.0 version:

       <!-- Only need the apache-tomcat jars tomcat-apr.jar, tomcat-coyote.jar, tomcat-http.jar, tomcat-util.jar
       (and tomcat-apr.jar only needed if actually using APR transport). None of these are needed unless
       using http server invoker -->
       <import componentref="apache-tomcat">
       <compatible version="5.5.15"/>
       </import>
      


      This http transport should really be a separate artifcat that can be selected based on the included web container version, JBREM-705. For now I'm commenting this out.

        • 1. Re: jboss/remoting 2.2.0.Alpha7 not compatible with jboss5

          Ok. I'm personally fine with not having the dependency listed within the component-info.xml at all (but guess can see why would be good to declare it).

          Problem for me is testing all the different versions. Remoting would probably work with most anything in the 5 series, but getting all the versions and testing each of them is a huge time drain. Especially if include apr as well.

          • 2. Re: jboss/remoting 2.2.0.Alpha7 not compatible with jboss5
            timfox

            Our jboss messaging test run now fails to run, since the build no long pulls in apache-tomcat because (needed for our tests that involve the remoting http transport) it is not listed in the remoting dependencies.

            I have added an explicit dependency to apache-tomcat in our project, but I have no idea what version to use now, since it is not listed as an explicit remoting depency.

            How can I find out which version I should use? (I have guessed 5.5.20 for now)

            Surely I should only be using the version that remoting is tested against which should be that listed in the remoting dependencies (and is not anymore) ?

            • 3. Re: jboss/remoting 2.2.0.Alpha7 not compatible with jboss5
              timfox

              Ok, I can see it is 5.15 by looking at the commented out section in component-info.xml.

              What is the long term solution for this? I don't think us manually enforcing dependencies by looking at commented out sections in other projects' component-info.xml is a good way to go...

              • 4. Re: jboss/remoting 2.2.0.Alpha7 not compatible with jboss5
                ovidiu.feodorov

                apache-tomcat is a dependency of Remoting. Remoting can't do HTTP unless those jars are present. Messaging, as a Remoting dependent, shouldn't be in the position to decide what apache-tomcat version Remoting uses. From our perspective, we don't care, and we don't want to be forced to care.

                All we care about is that our tests pass with the specific Remoting version listed in our dependency metadata.

                So, having to list apache-tomcat among our dependencies is wrong.

                If Remoting declares itself compatible on apache-tomcat 5.5.15, and this breaks compatibility with jbossweb 2.0.0, then jbossweb and Remoting teams need to work this out and qualify a apache-tomcat that is acceptable for both parties.

                Also, they need to do this in such a way that doesn't require uncomment stuff in configuration-info.xml and leave Tim and I wondering for hours why is that our testsuite fails.

                • 5. Re: jboss/remoting 2.2.0.Alpha7 not compatible with jboss5
                  starksm64

                  The http transport dependency and its dependency on an http stack needs to be moved into a separate artifact as I outlined in JBREM-705. Whatever its compatible with should be declared in that artifact.

                  • 6. Re: jboss/remoting 2.2.0.Alpha7 not compatible with jboss5

                    Looks like only solution so that JBossAS does not have conflict (where remoting specifies dependency on apache-tomcat) is to remove import of apache-tomcat from the remoting component-info.xml (as well as declaration of jboss-remoting-http.jar as an artifact). Then create a new jboss/remoting-http within the repository that declares jboss-remoting-http.jar as artifact and export with apache-tomcat as import.

                    Doing this would mean that messaging would then need to either pick out all the componentized remoting artifacts they need (i.e. jboss-remoting-core.jar, jboss-remoting-http.jar, etc.) or just get jboss-remoting.jar and jboss-remoting-http.jar.

                    • 7. Re: jboss/remoting 2.2.0.Alpha7 not compatible with jboss5
                      ovidiu.feodorov

                       

                      "tom.elrod@jboss.com" wrote:
                      Doing this would mean that messaging would then need to either pick out all the componentized remoting artifacts they need (i.e. jboss-remoting-core.jar, jboss-remoting-http.jar, etc.) or just get jboss-remoting.jar and jboss-remoting-http.jar.


                      Messaging needs remoting HTTP support and it really doesn't care what version of Apache (or Jetty, or whatever) remoting uses. How would I know what jboss-remoting-http.jar version matches jboss-remoting.jar I am using?

                      Let's say that Messaging takes a wild guess and arbitrarily decides that it should use Tomcat 5.5.15. That would create a conflict with JBossWeb 2.2.0.

                      If Messaging instead declares it wants to a Tomcat version that makes JBossWeb happy, we end using Remoting with an untested tomcat version.

                      How would our dependency map look like if you go for piecemeal jboss-remoting.jar/jboss-remoting-http.jar?

                      • 8. Re: jboss/remoting 2.2.0.Alpha7 not compatible with jboss5

                        If went piecemeal, would need to reference http://labs.jboss.com/portal/jbossremoting/docs/guide/ch04.html for the components.

                        As for the tomcat libs, should only be a problem if web container is using the same classloader as jbossas (which at least used to not be the default). If web container is using same classloader, then is certainly a problem (and a known one for a while - http://jira.jboss.com/jira/browse/JBAS-2766). I don't know how to solve this other than making sure remoting is tested with all the different tomcat releases and hope that there are no changes to the tomcat api between its releases that would cause remoting to not be compatible with all the versions.

                        On top of all this is JBossWeb which seems to not be using apache-tomcat libs at all. Don't know what their API looks like, but if is different from tomcat connector api, will need to re-write a remoting http server for it.

                        • 9. Re: jboss/remoting 2.2.0.Alpha7 not compatible with jboss5
                          starksm64

                          If remoting breaks out http, then jbm has to as well. You cannot have a cross product of dependencies on the same type of component (http stack in this case) in an artifact as its just going to pull in conflicting dependencies for no reason. Its the consumer remoting and jbm that are going to define which remoting and jbm artifact correspond to the http stack. Start breaking project up along the lines of their dependencies so that they can be properly consumed.

                          • 10. Re: jboss/remoting 2.2.0.Alpha7 not compatible with jboss5
                            ovidiu.feodorov

                            I don't understand.

                            What dependency do I need to break out? I don't touch HTTP code, I don't care about HTTP code.

                            My only dependency is Remoting and I only have a piece of configuration that says "bisocket" or "http". Remoting can implement HTTP using smoke signals, for what I care.

                            IF we start to get into this, maybe it's time to ditch remoting and start thinking about our own transport.


                            • 11. Re: jboss/remoting 2.2.0.Alpha7 not compatible with jboss5
                              starksm64

                              If you don't care about http, then why did you say "Messaging needs remoting HTTP support...". That dependency links to an http stack regardless of what it is. As its something jbm does not control, it should be a dependency that is isolated in a separate artifact so that the correct stack can be included. The correct stack being whatever is aggregating jbm and http stacks.

                              • 12. Re: jboss/remoting 2.2.0.Alpha7 not compatible with jboss5
                                ovidiu.feodorov

                                 

                                "scott.stark@jboss.org" wrote:
                                If you don't care about http, then why did you say "Messaging needs remoting HTTP support...". That dependency links to an http stack regardless of what it is.


                                OK. That's fine with us. But why do I have to specify a specific HTTP stack version? Why can't we just say "we use Remoting 2.2.0 and whatever Remoting 2.2.0 uses as HTTP stack"

                                Remoting 2.2.0 was presumably tested with several HTTP stacks, let them decided what's best.

                                IF I have to specify that I depend on jboss-remoting-core.jar 2.2.0 and jboss-remoting-http.jar 2.2.0, that's perfect. If this is all we need to do, then the story is over. We're happy.

                                • 13. Re: jboss/remoting 2.2.0.Alpha7 not compatible with jboss5
                                  starksm64

                                  For jboss5 that is probably all that is needed. If remoting has to create remotting-http-jbossweb, remoting-http-tomcat5, remoting-http-jetty6, ... then the jbm piece that depends on the http stack needs to be separable so that the required http stack is selected.

                                  • 14. Re: jboss/remoting 2.2.0.Alpha7 not compatible with jboss5
                                    ovidiu.feodorov

                                    Beautiful.

                                    We're looking forward to remoting-http-jbossweb, remoting-http-tomcat5, etc.

                                    Maybe this will also solve our HTTP stress test failures? :)

                                    1 2 Previous Next