I think if you do not have JSF_HOME set to point to a JSF reference
implementation yet, you need to do that. Right, Rich?

-----Original Message-----
From: Richard Feit 
Sent: Thursday, December 16, 2004 5:08 PM
To: Beehive Developers
Subject: Re: patch for jira 129

I just do 'ant drt' from netui/test/webapps/jsf.  But I haven't tried it

in a while.

Bryan Che wrote:

> Thanks, Julie.  Does anyone know how the jsf stuff gets run?  I assume

> that I need to update the jsf server.test waitfor.url as well, but I 
> want to test it.
>
> Bryan
>
> Julie Zhuo wrote:
>
>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>
>

Reply via email to