Hi Adrian, Your workaround sounds ok, but I have some 20 ear-scoped applications, with the same single offending method in each, so I decided to stay with my serialization "below the API" with a byte[] arg. (I can do this by myself, but the management GUI is written by Mehrdad (remember him?), and I don't wan't to bother him with like managing 20 different Adaptors...8-)
But now I came around another problem with this classloading deficiency: I have quite some management methods of the type "setSomeURL(String x)", which are typically with a default setting like "ressource:someFile.xml", which points to a file inside the ear. The setters are implemented through TCL, and so these setters fail, even when the provided String is the same as previously obtained through the getter. (Pressing the "Apply"-Button on the console) I probably should save a copy of the TCL during create() or even use the (banned!) Class.forName. Or do we have a standard method to obtain the MBean classloader at runtime from another Thread (beside looking up the UCL throgh JMX)? Thank you, Michael ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
