beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Osborne <patrick.osbo...@bea.com>
Subject Re: patch for jira 129
Date Sat, 18 Dec 2004 00:20:17 GMT

Hi Bryan and Eddie

An approach you may find useful for determining if the server is up (not 
your webapp) is to ping the tomcat 'manager' webapp.  The manager webapp 
is used to deploy user webapps via http calls and is deployed on startup 
by Tomcat.  By hitting a URL like http://localhost:8080/manager and 
waiting for the page to return a status code < 400, you can determine 
that the manager webapp is ready for business and therefore your webapp 
can be deployed.  I've sucessfully used this approach for automating 
beehive for perf testing.  Ant has some support for looking at status 
codes in <waitfor> that will handle this approach.

Patrick,


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
>>>>>
>>>>>
>>>>
>>>
>


Mime
View raw message