Hi Brian, for the dist-test here is what I recommend based on the changes you have in your patch.
1. In the test-dist.properties file, do the following - <property name="webapp.waitfor.url" value="http://localhost:8080/${webapp.name}"/> + <property name="server.root.url" value="http://localhost:8080"/> + <property name="webapp.waitfor.url" value="${server.root.url}/${webapp.name}"/> 2. In the testWebBuild.xml, do the following <target name="drt" description="Run the drt suite with full server start / stop support."> <ant dir="${test.dir}" antfile="${test.dir}/ant/testRecorder.xml" inheritAll="false" target="server.test"> - <property name="waitfor.url" value="${webapp.waitfor.url}"/> + <property name="waitfor.url" value="${server.root.url}"/> <property name="suite.name" value="drt"/> <property name="playback.webapps" value="${webapp.name}"/> <property name="drt.mode" value="true"/> <property name="drt.cc.mode" value="true"/> <property name="formatter.type" value="xml"/> <property name="formatter.usefile" value="true"/> <property name="os.BEEHIVE_TEST_HOME" value="${test.dir}"/> <property name="os.CATALINA_HOME" value="${tomcat.dir}"/> <property name="os.BEEHIVE_HOME" value="${dist.home}"/> <property name="_report.root.dir" value="${test.dir}/build/testResults/testRecorder"/> <property file="${test.dir}/test-dist.properties"/> </ant> </target> <target name="bvt" description="Run the bvt suite with full server start / stop support."> <ant antfile="${test.dir}/ant/testRecorder.xml" inheritAll="false" target="server.test"> - <property name="waitfor.url" value="${webapp.waitfor.url}"/> + <property name="waitfor.url" value="${server.root.url}"/> <property name="suite.name" value="bvt"/> <property name="playback.webapps" value="${webapp.name}"/> <property name="drt.mode" value="true"/> <property name="drt.cc.mode" value="true"/> <property name="formatter.type" value="xml"/> <property name="formatter.usefile" value="true"/> <property name="os.BEEHIVE_TEST_HOME" value="${test.dir}"/> <property name="os.CATALINA_HOME" value="${tomcat.dir}"/> <property name="os.BEEHIVE_HOME" value="${dist.home}"/> <property name="_report.root.dir" value="${test.dir}/build/testResults/testRecorder"/> <property file="${test.dir}/test-dist.properties"/> </ant> </target> 3. To test it out, you need to build the test package first by "ant build.test.dist" at the trunk. You then need to get the test package archive from /beehive/build/testDistArchives. Unzip the package and then follow the README.txt. Hope this is helpful. Thanks for your effort. Julie -----Original Message----- From: Bryan Che [mailto:[EMAIL PROTECTED] Sent: Thursday, December 16, 2004 12:27 PM To: Beehive Developers Subject: Re: patch for jira 129 I have a patch that fixes the drt suite by setting the waitfor.url for server.test to a server.root.url property in /netui/test/webapps/drt/build.xml. That fixes the netui.drt tests. But, I also see calls to server.test in other places: find . -name "*.xml" | xargs grep "server.test" ./netui/test/webapps/testRecorder-test/build.xml: <ant antfile="${test.dir}/ant/testRecorder.xml" inheritAll="false" target="server.test"> ./netui/test/webapps/jsf/build.xml: <ant antfile="${test.dir}/ant/testRecorder.xml" inheritAll="false" target="server.test"> ./netui/test/webapps/drt/build.xml: <ant dir="${test.dir}" antfile="${test.dir}/ant/testRecorder.xml" inheritAll="false" target="server.test"> ./netui/test/webapps/drt/build.xml: <ant antfile="${test.dir}/ant/testRecorder.xml" inheritAll="false" target="server.test"> ./netui/test/ant/testRecorderCore.xml: <target name="server.test" description="Runs Test Recorder regression tests"> ./netui/test/dist-test/ant/testWebBuild.xml: <ant dir="${test.dir}" antfile="${test.dir}/ant/testRecorder.xml" inheritAll="false" target="server.test"> ./netui/test/dist-test/ant/testWebBuild.xml: <ant antfile="${test.dir}/ant/testRecorder.xml" inheritAll="false" target="server.test"> How do I run these other tests to verify that the proper url is being checked? There seems to be stuff for jsf and dist-test. Bryan Bryan Che wrote: > Hi Eddie, you're right that the <waitfor> would help servers that do a > delayed startup. I don't think that moving it to the "ensure.deployed" > target would be better--the target that starts the server should be > responsible for making sure that it's running. > > I'll add another property, server.root.url, and have the server.test > target wait for that url before trying to deploy in order to solve the > immediate bug. > > I also agree that the factoring is somewhat convoluted. I'd like to do > something similar for the test suite that I did to get the distribution > to support JOnAS: abstract out all the server-related info into > application-server-specific files and then configure switching > application servers through a property. If that sounds reasonable (and > my earlier patch seems ok), I can send out more details on that work. > > Bryan > > Eddie O'Neil wrote: > >> Bryan-- >> >> One more thing here... >> >> It would be possible to move this <waitfor> into the >> "ensure.deployed" target which is called-back on the application's >> build file. Then, the app controls waiting for the server to start >> and/or for the application to deploy. >> >> In the long run, the factoring here doesn't seem quite right for >> supporting an application build separate from an application deploy. >> They're different problems, and in order to run an app across >> different servers (and different deploy commands / semantics), there's >> probably some work to do here. I know you've done work to get things >> running on JOnAS (will still get that patch in!) -- want to propose >> something that might help solve this problem for you? >> >> Eddie >> >> >> >> Eddie O'Neil wrote: >> >>> Bryan-- >>> >>> Hey; actually, these lines serve a purpose there. When starting a >>> server that isn't immediately available, these are intended to >>> continually ping a server until the specified "waitfor.url" is >>> available. If a server takes a while to start, the HTTP port may not >>> be running yet, and this keeps the build from failing out immediately >>> after forking the server. >>> >>> But, I think you've hit on the issue here -- the "waitfor.url" >>> passed from netui/test/webapps/drt/build.xml is looking for a webapp >>> that's running at http://localhost:8080/coreWeb. The first time the >>> tests run, that's obviously not available yet, which is why the tests >>> fail. >>> >>> You might try taking a crack at changing this waitfor.url to >>> http://localhost:8080 to try to hit the default webapp and see if >>> that helps solve the problem. >>> >>> Thanks for digging on this one. :) >>> >>> Eddie >>> >>> >>> >>> Eddie O'Neil wrote: >>> >>>> Bryan-- >>>> >>>> Hey, thanks. Great that you took a look at this. >>>> >>>> I'll give it a look over and should be able to submit here in a bit. >>>> >>>> Eddie >>>> >>>> >>>> >>>> Bryan Che wrote: >>>> >>>>> Hi, I submitted a patch for jira 129 earlier today but didn't see >>>>> any e-mail alerts sent out about it. So, I figured I'd e-mail out >>>>> to let people know so that someone can apply it. >>>>> >>>>> http://nagoya.apache.org/jira/browse/BEEHIVE-129 >>>>> >>>>> Bryan >>>>> >>>>> >>>> >>> > -- Bryan Che Red Hat, Inc. 10 Technology Park Westford, MA 01886 978-392-3107 [EMAIL PROTECTED]
