13 Replies Latest reply on Feb 26, 2007 8:20 AM by kabirkhan

    Messaging 1.2.0 integration with JBoss 5.0.Beta

    ovidiu.feodorov

      I've gave it a try yesterday night. I got it working on my machine, and the integration tests pass in a significant percentage. However, there are a couple of things that need to be cleared out, either internally or with third parties. Here's a list:


      1. jbossws depends on Remoting 2.2.0.Alpha2 and we need Remoting 2.2.0.Alpha7. Unless jbossws doesn't declare itself compatible with Alpha7, we can't go unscoped.

      2. For some reason that's not entirely clear to me, there's a apache-logging version conflict in apache-tomcat. I don't know how to fix this. Scott?

      3. For real clustering, hypersonic won't do. We need a real database. However, I probably could bend the configuration files so if started in non-clustered mode, Messaging would use hypersonic, so people can give Messaging a try in non-clustered configuration. Again, for serious stuff, people should get rid of hypersonic. If we go for MySQL, we'll need to install drivers, etc. This is related to point 5. below.

      4. I badly hacked org.jboss.mq.server.jmx and I need to return to it to do it right. Scott, what do we need that package for?


      5. Need two different configurations (clustered and non-clustered). Need to modify jboss's build system for that. This way, we avoid needing jgroups.jar in non-clustered mode.

        • 1. Re: Messaging 1.2.0 integration with JBoss 5.0.Beta
          brian.stansberry

           

          "ovidiu.feodorov@jboss.com" wrote:

          5. Need two different configurations (clustered and non-clustered). Need to modify jboss's build system for that. This way, we avoid needing jgroups.jar in non-clustered mode.


          Are you thinking of doing this just to avoid needing jgroups.jar in server/default/lib? If so, I'd say we should just include the jar there. There's a JIRA for shared web sessions that I'll do for 5.0 that in default would use JBoss Cache in LOCAL (non-replicated) mode. Even in local mode JBC requires jgroups on the classpath, so jgroups.jar is very likely to end up in server/default/lib anyway.

          • 2. Re: Messaging 1.2.0 integration with JBoss 5.0.Beta
            starksm64

            1. There needs to be a common compatible version between jbossws and jbm.

            2. Details are needed.

            3. We need a hypersonic configuration for the default, unclustered config. What the integration needs to be for clustering will have to be defined as an integration task.

            4. This is contains the jms mbeans for creating destinations.

            5. Yes. Introducing a mysql dependency is not an option though.

            • 3. Re: Messaging 1.2.0 integration with JBoss 5.0.Beta
              starksm64

               

              "bstansberry@jboss.com" wrote:
              "ovidiu.feodorov@jboss.com" wrote:

              5. Need two different configurations (clustered and non-clustered). Need to modify jboss's build system for that. This way, we avoid needing jgroups.jar in non-clustered mode.


              Are you thinking of doing this just to avoid needing jgroups.jar in server/default/lib? If so, I'd say we should just include the jar there. There's a JIRA for shared web sessions that I'll do for 5.0 that in default would use JBoss Cache in LOCAL (non-replicated) mode. Even in local mode JBC requires jgroups on the classpath, so jgroups.jar is very likely to end up in server/default/lib anyway.


              Why is that?


              • 4. Re: Messaging 1.2.0 integration with JBoss 5.0.Beta
                ovidiu.feodorov

                 

                "bstansberry@jboss.com" wrote:
                Are you thinking of doing this just to avoid needing jgroups.jar in server/default/lib? If so, I'd say we should just include the jar there. There's a JIRA for shared web sessions that I'll do for 5.0 that in default would use JBoss Cache in LOCAL (non-replicated) mode. Even in local mode JBC requires jgroups on the classpath, so jgroups.jar is very likely to end up in server/default/lib anyway.


                OK. Regardless, JBM non-clustered should not depend on JGroups. It's good that we have a choice, though.

                • 5. Re: Messaging 1.2.0 integration with JBoss 5.0.Beta
                  brian.stansberry

                   

                  "scott.stark@jboss.org" wrote:
                  "bstansberry@jboss.com" wrote:
                  There's a JIRA for shared web sessions that I'll do for 5.0 that in default would use JBoss Cache in LOCAL (non-replicated) mode. Even in local mode JBC requires jgroups on the classpath, so jgroups.jar is very likely to end up in server/default/lib anyway.


                  Why is that?


                  Why is jgroups required even in LOCAL mode? Basically because JBC is very tightly coupled to JGroups. In 1.x, TreeCache is actually a subclass of the JGroups RpcDispatcher (not in 2.0, but RpcDispatcher is still imported). From that, the class that represents an invocation through the JBC interceptors is a subclass of a JGroups MethodCall. The JGroups View class pops up here and there too.

                  There's a JIRA to eliminate the coupling but IIRC it's not on anything but a long term roadmap.

                  • 6. Re: Messaging 1.2.0 integration with JBoss 5.0.Beta
                    ovidiu.feodorov

                     

                    "scott.stark@jboss.org" wrote:

                    "ovidiu.feodorov@jboss.com" wrote:

                    2. For some reason that's not entirely clear to me, there's a apache-logging version conflict in apache-tomcat. I don't know how to fix this. Scott?


                    2. Details are needed.


                    Details:

                    BUILD FAILED
                    C:\work\src\svn\jboss-head2\build\build.xml:896: The following error occurred while executing this line:
                    C:\work\src\svn\jboss-head2\build\build-thirdparty.xml:144: A versioning problem exists:
                    Component: apache-logging is at version: 1.1.0.jboss
                     but it is also required to be compatible with: [Compatible@8c4a77{id=null, version=1.0.3}, Compatible@6d0040{id=null, version=1.0.4.1jboss}, Compatible@2b9406{id=null, version=1.0.4jboss}]
                     by: apache-tomcat
                    


                    Standing by, in case you need more info.





                    • 7. Re: Messaging 1.2.0 integration with JBoss 5.0.Beta
                      starksm64

                      Your repository.jboss.com/jboss/web/2.0.0.snapshot contents are out of date then. The current version is compatible with 1.1.0.jboss:

                      [starksm@succubus 2.0.0.snapshot]$ cat component-info.xml
                      <project name="jboss/web-component-info">
                      
                       <component id="jboss/web"
                       licenseType="lgpl"
                       version="2.0.0.snapshot"
                       description="JBoss Web 2.0.0">
                       <artifact id="annotations-api.jar"/>
                       <artifact id="el-api.jar"/>
                       <artifact id="jasper-jdt.jar"/>
                       <artifact id="jbossweb.jar"/>
                       <artifact id="jbossweb-extras.jar"/>
                       <artifact id="jsp-api.jar"/>
                       <artifact id="servlet-api.jar"/>
                       <artifact id="jbossweb-src.zip"/>
                      
                       <import componentref="apache-logging">
                       <compatible version="1.0.3"/>
                       <compatible version="1.0.4jboss"/>
                       <compatible version="1.0.4.1jboss"/>
                       <compatible version="1.0.5.GA-jboss"/>
                       <compatible version="1.0.5.SP1-jboss"/>
                       <compatible version="1.1"/>
                       <compatible version="1.1.0.jboss"/>
                       </import>
                       <export>
                       <include input="annotations-api.jar"/>
                       <include input="jasper-jdt.jar"/>
                       <include input="jbossweb.jar"/>
                       <include input="jbossweb-extras.jar"/>
                       <include input="jsp-api.jar"/>
                       <include input="servlet-api.jar"/>
                       <include input="el-api.jar"/>
                       </export>
                       </component>
                      
                      </project>
                      



                      • 8. Re: Messaging 1.2.0 integration with JBoss 5.0.Beta
                        ovidiu.feodorov

                        No.

                        My jboss/web component-info.xml is identical with what you pasted below (or above).

                        Before compiling the head, I also deleted thirdparty, just to be sure.

                        • 9. Re: Messaging 1.2.0 integration with JBoss 5.0.Beta
                          starksm64

                          There should not be any apache-tomcat referenced. The component-info.xml is for jboss/web, not apache-tomcat. How is this being imported? Its not coming from the jboss-head/build/build-thirdparty.xml:

                          [starksm@succubus build]$ grep tomcat build-thirdparty.xml
                          [starksm@succubus build]$

                          • 10. Re: Messaging 1.2.0 integration with JBoss 5.0.Beta
                            ovidiu.feodorov

                            I found out, it's our build-thirdpaty.xml:

                             <!-- Need this otherwise project doesn't build in Eclipse -->
                             <componentref name="apache-logging" version="1.0.4.1jboss"/>
                            


                            How that got there, I have no idea. I'll comment it out and see who starts crying. (I don't use eclipse).

                            • 11. Re: Messaging 1.2.0 integration with JBoss 5.0.Beta
                              kabirkhan

                              Messaging 1.2.0.CR1 in head broke the build:
                              http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021401#4021401

                              It has been fixed, but please verify if it works as expected with aop.2.0.0.alpha3

                              • 12. Re: Messaging 1.2.0 integration with JBoss 5.0.Beta
                                ovidiu.feodorov

                                Messaging 1.2.0.CR1 in the head did not break the build. I have tested the build personally, and everything was compiling just fine. Check out a 23/Feb/07 02:21 AM PST snapshot of the head and try for yourself, if you don't belive me.

                                AOP 2.0.0.Alpha3 in the head broke the build.

                                Before checking-in the change in SVN, you should have updated the head, as it was, delete 'thirdparty', and try to build locally, and you'd have seen that it breaks, because Messaging declars compatibility with AOP 1.5.x only.

                                The next step would have been to post on the Messaging development forum, or to me or Tim personally, we don't mind, or create a Messaging JIRA issue and ask us to validate 1.2.0.CR1 with AOP 2.0.0.Alpha3, by running our testsuites with AOP 2.0.0.Alpha3.

                                That did not happen, somebody just modified our component-info.xml in the head, as in "oh well, who cares ...".

                                Anyway, http://jira.jboss.org/jira/browse/JBMESSAGING-892

                                • 13. Re: Messaging 1.2.0 integration with JBoss 5.0.Beta
                                  kabirkhan

                                  Hmmm, yes I replied late at night and hadn't thought through what I was saying :-)

                                  I updated build-thirdparty.xml to "your" version and the build works. But the snapshot of AOP in trunk is a snapshot from the 2.0 branch. Why this works I am not sure. Maybe snapshots aren't checked properly for compatibility?

                                  In any case for future reference, head always uses AOP 2.0.0 releases/snapshots