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 Mon, 20 Dec 2004 14:32:22 GMT
Hi Patrick, from looking at the Tomcat logs, it looks like Tomcat 
deploys its webapps before starting its http listener.  So, waiting for 
Tomcat's root URL should also be a sufficient test to see if a new 
webapp can be deployed.  Also, for portability's sake, I would prefer to 
wait for a server's root url and then let the task that tries to deploy 
the webapp also wait a bit (which is the current case now).  That way, 
we can support app servers that don't have a manager app for checking.

Bryan

Patrick Osborne wrote:
> 
> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>
> 

-- 
Bryan Che
Red Hat, Inc.
10 Technology Park
Westford, MA 01886
978-392-3107
bche@redhat.com

Mime
View raw message