marc,
I'm sorry, but I'm unsure what you mean by this question. I'm possibly a
little over my head here, but I assume that when I start jBoss with
"-classic -Xdebug -Xnoagent
-Xrunjdwp:transport=dt_socket,server=y,address=7081,suspend=n" I'm telling
it that I want to debug on address 7081. The server, I imagine, then routes
request through port 7081 to beans it has deployed. Now here I'll really
guess...maybe the server correctly registers the bean on initial/start-up
deployment in some routing table so that when request come in, it sends them
to the appropriate bean. If this "table" (that I made up) is not updated
upon re-deployment, it would be the case that debug request are being sent
to the "old" location of the bean. This scenario is consistent with my
perceived results. It would be the case if the "changed class loader"
didn't reregister the beans location correctly to handle debug requests.
I'm guessing something like this since sometimes the debugger and jBoss will
hang waiting for responses from each other if I iterate my experiment
(redeploy bean, attach debugger, redeploy bean...). At that point I have to
shut down the server to get my debugger to shut down (or vice-versa).
BTW, I've upgraded to the new binaries and this problem remains. The
real-world scenario of wanting to debug a redeployed bean without rebooting
jBoss will certainly occur a lot.
Thanks,
Jeff Mc.
> SECOND: Testing remote debugging of redeployed bean.
> 1) Start jBoss with ONE bean deployed.
> 2) Touch the jar file of the bean causing redeployment
> 3) Start debugger, attach to remote process, set breakpoint in bean
> 4) Run test client, breakpoint IS NOT HIT.
Do they work from classloaders? we change the class loader and that is
about it.
marc
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
