geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Redeploy problems in branches/1.1.1
Date Thu, 03 Aug 2006 17:19:08 GMT
On Aug 3, 2006, at 10:11 AM, Aaron Mulder wrote:

> On 8/3/06, Dain Sundstrom <dain@iq80.com> wrote:
>> > http://issues.apache.org/jira/browse/GERONIMO-2269
>>
>> My guess is this one is a side effect of the next one, so I'd fix
>> 2270 first and rerun this test case.
>
> I will, though I disagree with your guess -- 2270 is a problem before
> the call ever gets to the server, while 2269 is a problem after the
> call has gone to the ConfigurationManager and the app has been
> distributed and the new version is being started.

Sorry, I don't understand what you are saying.

My guess is based on this text "UPDATE: a simple redeploy of the  
working application causes the error"  If there is a problem during  
redeploy, I'd question any JIRA about problems after that.

>> > http://issues.apache.org/jira/browse/GERONIMO-2270
>>
>> Didn't you write the redeploy code?
>
> No, couldn't have been me -- my code never has bugs!  :)  I'm sure I
> should look at 2270.  I definitely can't take full credit for the
> version-less redeploy because that goes through ConfigurationManager,
> and I dropped the ball on trying to refactor that code.

I wrote big chuncks of this, but I think you wrote the part that  
matches versionless ids to preexisting installations.

> But the more relevant question probably is -- how can we end up with a
> dead proxy error when looking up a JNDI resource?  The database pool
> wasn't redeployed so a reference to it shouldn't become dead, and the
> pool isn't in the web app module so the version number for the
> database pool shouldn't have changed...  Its a little confusing.

My guess is the pool was actually redeployed, but the only way to  
tell is to sick a breakpoint in the code.

-dain

Mime
View raw message