Ulrich,
On reflection I do not think classloading is your issue.
I do think so, because just now another app has started to fail. It doesn't find a class in a method that is exposed through the management interface, but it does find the class in other, non-MBean-methods within the same class. That is a clear indication for classloader problems, because in the case of the management MBean I depend on Phoenix calling this method and obviously Phoenix does not have the class that is used within the method. However, when I have control myself over calling the class I can find it.
Ahh that is interesting, I know a lot about that
Consider classloaders :
X Y
| |
--------------
JMX (or something) Z
| |
----------------------------
|
SYSIf you are trying to createa local presence for X or Y but using JMX (or RMI, or ObjectInoutStream.readObject() or AltRMI) in a higher classloader, it can no nothing of where the classes are available. I have fixed it for AltRMI so that EOB works in the sense (it juggles many beans at lower classloaders). I also fixed it for Cornerstone's store over a year year ago (see ClassLoaderInputStream in excalibur and its uses). It starts to stretch one's mental modelling of a running JVM..
Hey, man start at the cronalogical beginning and progressivel move the traces thru the code. I am doing it at the moment wiith AltRMI on a hang issue.You are going to have to temporarily fork the latest phoenix and put old fashioned debug messages in. It is a good way of understanding phoenix.
Yes, obviously. But it would help if I knew where the classloading takes place, so I could put debug statements there.
- PAul
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
