Contradictory classloading on different JBoss instances

[asydbarret]

Hey there...

I have a strange problem...when I deploy my MBean services on my development JBoss instance (my setup is, that all my proprietary classes (POJO's, EJBs and even the MBean classes) are referenced from the Jboss's classpath setup directly in their "bin" repository) I get "ClassNotFound exception" as soon as the MBean service tries to run its start method.

I managed to get rid of this problem by defining a custom classloader for the MBean services ... but only with the expense of not being able to debug them anymore (I had to pack the MBEans in an SAR archive and deploy them on the Jboss manually, but that made me lose the connection to the appropriate repository within my IDE - Eclipse...so I cannot access the classes from Eclipse for debugging anymore)

the thing that is really weird about my situation, is that when I tried out my deployment setup in a different environment (resp. on another JBoss on another machine)...it went OK even without the need to specify a custom classloader for the MBean Services.
I investigated a possible difference in the Jboss's configuration, but I could not locate any difference... I was wondering : How can a same SAR archive behave so differently on different JBoss servers, that seem to be configured similarily ?

[asydbarret]

Ok...I have to rephrase and turn around the previous post, since as I read it now it is 1] confusing 2] not very informational 3] not the actual problem Im having ...

so...

the first post still applies, but only in the part that my MBean services on my development environment work only if I define a custom classloader repository for them... otherwise I get "ClassNotFound exception" on deployment time (for example, one of my MBeans implements JMS Message Listener and the exception is thrown exactly on this interface..which is a standart class of JBoss)

but the fact that when I deploy them with a custom ClassLoader for the MBeans causes that I no longer have them in the same container as the rest of the Jboss - meaning that I have to define JNDI Port and BindAddress when instancing an Initial Context instead of simply relying on the default one ... AND it also means that I can't use Local Interfaces of my EJB's eventhough I'm accessing them from the very same JBoss deployment...again, I believe this has to do something with the custom classloader and its different domain from the default one...

BUT...when I deploy my MBeans on a different JBoss server I actually have to get rid of the custom ClassLoader for them before they start working and if I do so...the SAR archive seems to suddenly be in the same domain/container as the other deployed services and EJB ... I can do JNDI calls through the default InitialContext and (although I havent tested that yet) I guess I could even use my Local EJB Interfaces instead of the standart default ones ...

can anyone post some remarks on such a situation