Beehive
  1. Beehive
  2. BEEHIVE-195

Beehive Distribution should work with app servers besides just Tomcat

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: V1Beta
    • Fix Version/s: v1m1
    • Component/s: Build
    • Labels:
      None

      Description

      The Beehive distribution requires CATALINA_HOME to be set in order to pick up servlet api jars. It should instead be configurable to work with various app servers and pick up the servlet api jars anywhere. I will be attaching a patch to support this requirement.

      1. dist-appserver-patch.tar.gz
        2 kB
        Bryan Che
      2. appserver-patch.tar.gz
        3 kB
        Bryan Che

        Activity

        Hide
        Bryan Che added a comment -

        From the README:

        This is a patch to make the Beehive distribution easier to use with app
        servers other than Tomcat. It keeps the default support for Tomcat and
        keeps Beehive working "out of the box." But, it also makes using other
        app servers simpler for the user to configure.

        It does this by doing the following:

        • adds a new target, check.appserver.classpath, which verifies that the
          build classpath contains the Servlet API
        • makes the build target depend upon check.appserver.classpath. If a
          user doesn't have the Servlet API properly setup when he builds, he
          will see a helpful error message telling him to configure his app
          server classpath
        • moves the appserver.build.classpath path to a separate file,
          appserverClasspath.xml. Also, refactor setting the path so that it is
          now a refid pointing to an app-server-specific classpath. This makes
          it easier for a user to swap in a new app server: he has to edit only
          one file which controls the app server classpath and doesn't have to
          search through other, irrelevant targets. Also, there are build
          classpaths for both Tomcat and JOnAS in this file.

        To apply this patch, apply dist-appserver.patch and add
        user/appserverClasspath.xml to the trunk.

        There would still need to be documentation added somewhere explaining
        the need to edit appserverClasspath.xml appropriately for a user's app
        server.

        Show
        Bryan Che added a comment - From the README: This is a patch to make the Beehive distribution easier to use with app servers other than Tomcat. It keeps the default support for Tomcat and keeps Beehive working "out of the box." But, it also makes using other app servers simpler for the user to configure. It does this by doing the following: adds a new target, check.appserver.classpath, which verifies that the build classpath contains the Servlet API makes the build target depend upon check.appserver.classpath. If a user doesn't have the Servlet API properly setup when he builds, he will see a helpful error message telling him to configure his app server classpath moves the appserver.build.classpath path to a separate file, appserverClasspath.xml. Also, refactor setting the path so that it is now a refid pointing to an app-server-specific classpath. This makes it easier for a user to swap in a new app server: he has to edit only one file which controls the app server classpath and doesn't have to search through other, irrelevant targets. Also, there are build classpaths for both Tomcat and JOnAS in this file. To apply this patch, apply dist-appserver.patch and add user/appserverClasspath.xml to the trunk. There would still need to be documentation added somewhere explaining the need to edit appserverClasspath.xml appropriately for a user's app server.
        Hide
        Eddie O'Neil added a comment -

        Bryan--

        Hey; can you attach a unified diff file to this? It's hard to apply a patch to a bunch of files like this.

        You can make such a patch with:

        svn diff > appserver-patch.diff

        in the top-level directory.

        Feedback on the patch coming shortly...

        Thanks!

        Eddie

        Show
        Eddie O'Neil added a comment - Bryan-- Hey; can you attach a unified diff file to this? It's hard to apply a patch to a bunch of files like this. You can make such a patch with: svn diff > appserver-patch.diff in the top-level directory. Feedback on the patch coming shortly... Thanks! Eddie
        Hide
        Eddie O'Neil added a comment -

        Bryan--

        Hey, it seems that this patch was made against the tree before the build work I checked in last week.

        Is it possible that the wrong zip file was attached?

        Eddie

        Show
        Eddie O'Neil added a comment - Bryan-- Hey, it seems that this patch was made against the tree before the build work I checked in last week. Is it possible that the wrong zip file was attached? Eddie
        Hide
        Bryan Che added a comment -

        Oops, I attached the wrong file last time. This is the real patch. =p

        Show
        Bryan Che added a comment - Oops, I attached the wrong file last time. This is the real patch. =p
        Hide
        Eddie O'Neil added a comment -

        Couple of things:

        • the dist-appserver.patch file is only 64 lines long. Is that right (just making sure my .tar.gz file isn't corrupted)?
        • as far as the structure of appserverClasspath.xml – what would be the long-term plan here? Would we provide OOTB classpaths for a handful of appservers and let the Beehive developer just fill-in the classpath for any servers our Ant file doesn't support? Or would we include any appserver classpath that is contributed?

        One alternate way to go would be to just leave Tomcat as the default in appserverClasspath.xml and let them override it in order to define a "appserver.build.classpath".

        Or, we could just define it in a properties file and let it be overridden there, though I tend to prefer the <path>s as well.

        Thoughts?

        Show
        Eddie O'Neil added a comment - Couple of things: the dist-appserver.patch file is only 64 lines long. Is that right (just making sure my .tar.gz file isn't corrupted)? as far as the structure of appserverClasspath.xml – what would be the long-term plan here? Would we provide OOTB classpaths for a handful of appservers and let the Beehive developer just fill-in the classpath for any servers our Ant file doesn't support? Or would we include any appserver classpath that is contributed? One alternate way to go would be to just leave Tomcat as the default in appserverClasspath.xml and let them override it in order to define a "appserver.build.classpath". Or, we could just define it in a properties file and let it be overridden there, though I tend to prefer the <path>s as well. Thoughts?
        Hide
        Eddie O'Neil added a comment -

        One other thing here...this is a nice solution because it does isolate the Tomcat dependency from the buildWebapp.xml file, and it is isolated to the distribution (ie it doesn't affect the SVN tree at all). So, this may very well be a good way to go.

        Show
        Eddie O'Neil added a comment - One other thing here...this is a nice solution because it does isolate the Tomcat dependency from the buildWebapp.xml file, and it is isolated to the distribution (ie it doesn't affect the SVN tree at all). So, this may very well be a good way to go.
        Hide
        Bryan Che added a comment -

        Yes, the patch is correct. It's minimal because I'm just trying to make it easy via user-error checking and an isolated config file to change app servers--not necessarily build in complex support for all sorts of app servers.

        I'd imagine that over time, if there is community support for it, we could include various app server configs in appserverClasspath.xml. But, if community support dies out, then drop it from the next release. Including support for enough app servers to make things easier for a broad set of users would be nice, I think.

        Show
        Bryan Che added a comment - Yes, the patch is correct. It's minimal because I'm just trying to make it easy via user-error checking and an isolated config file to change app servers--not necessarily build in complex support for all sorts of app servers. I'd imagine that over time, if there is community support for it, we could include various app server configs in appserverClasspath.xml. But, if community support dies out, then drop it from the next release. Including support for enough app servers to make things easier for a broad set of users would be nice, I think.
        Hide
        Kenneth Tam added a comment -

        Bryan/Eddie, did this already get checked in?

        Show
        Kenneth Tam added a comment - Bryan/Eddie, did this already get checked in?
        Hide
        Eddie O'Neil added a comment -

        Actually, I think we still need to talk about this one some. In the beehive-dev list thread titled:

        proposal: new beehive build system

        we've tentatively come to the conclusion that we'd remove all of the app-container specific Ant for doing start / stop and deploy / undeploy / redeploy from the distribution. The issue is discussed in detail in the thread, but if we stick to the direction it was taking, we'd just close this bug as "won't fix".

        My $0.02...

        Show
        Eddie O'Neil added a comment - Actually, I think we still need to talk about this one some. In the beehive-dev list thread titled: proposal: new beehive build system we've tentatively come to the conclusion that we'd remove all of the app-container specific Ant for doing start / stop and deploy / undeploy / redeploy from the distribution. The issue is discussed in detail in the thread, but if we stick to the direction it was taking, we'd just close this bug as "won't fix". My $0.02...
        Hide
        Bryan Che added a comment -

        This patch doesn't support running/deploying/stopping appservers with beehive--it just addresses the build files' dependency on getting jars from tomcat. So, I think that it still is a good candidate for inclusion with beehive.

        I'm still waiting for all the apache paperwork to go through, so I don't have access to the tree yet to commit this myself. If we agree that abstracting out the build dependency is fine, then I can push this through once I finally gain access to the svn tree.

        Show
        Bryan Che added a comment - This patch doesn't support running/deploying/stopping appservers with beehive--it just addresses the build files' dependency on getting jars from tomcat. So, I think that it still is a good candidate for inclusion with beehive. I'm still waiting for all the apache paperwork to go through, so I don't have access to the tree yet to commit this myself. If we agree that abstracting out the build dependency is fine, then I can push this through once I finally gain access to the svn tree.
        Hide
        Bryan Che added a comment -

        Pushing Fix Version to v1 as this isn't necessary for beta, and Apache still hasn't given me access to the svn tree. If it turns out that I get access in time, I'll revisit the issue for V1Beta.

        Show
        Bryan Che added a comment - Pushing Fix Version to v1 as this isn't necessary for beta, and Apache still hasn't given me access to the svn tree. If it turns out that I get access in time, I'll revisit the issue for V1Beta.
        Hide
        Bryan Che added a comment -

        This issue has been resolved, and beehive can work with other app servers due to property files.

        Show
        Bryan Che added a comment - This issue has been resolved, and beehive can work with other app servers due to property files.

          People

          • Assignee:
            Bryan Che
            Reporter:
            Bryan Che
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development