beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Che <b...@redhat.com>
Subject Re: patch for jira 129
Date Thu, 16 Dec 2004 19:27:10 GMT
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
bche@redhat.com

Mime
View raw message