OK, well, I'm working on it. :)
Thanks,
Aaron
On 8/3/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
On Aug 3, 2006, at 10:11 AM, Aaron Mulder wrote:
> On 8/3/06, Dain Sundstrom <[EMAIL PROTECTED]> 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
