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
