Besoin d'aide compréhension JNDI et un ClassCastException particulier J2EE

Question

I ai une application d'entreprise A et B. déployée (en WLS 10.0). A est le "cadre", B est une application client. Le client émet les appels suivants:

Object o = ctx.lookup(jndiName); // line 1
cf = (ConnectionFactory) o; // line 2

ConnectionFactory est une interface, définie comme suit:

public interface ConnectionFactory 
    extends java.io.Serializable, javax.resource.Referenceable {
    ...
}

Qu'est-ce qui se passe est:

1. Si le pot contenant la classe d'interface est sur le chemin de classe du système, la ligne 2 est exécuté fin
2. Si la classe d'interface est pas sur le système classpath, mais emballé avec les applications séparément, la ligne 2 jette un ClassCastException (qui a le texte informatif que le joint est un ConnectionFactoryImpl)

Pourquoi est-ce possible? Je suppose que la recherche JNDI retourne uniquement un bout à l'objet distant (je suis juste en ce moment?), Alors pourquoi est-ce important si le classloader de la classe d'interface sont différents?

Le type de réponse que j'attendre:

1. Oui, il devrait se produire la façon dont vous l'expérience, parce que ...
2. Non, il ne devrait pas se produire de cette façon, parce que si ... alors ..., donc il y a quelque chose de louche dans votre configuration
3. La situation que vous avez décrite est très étrange, êtes-vous sûr de ne pas manquer un moment quelque part?
4. ...:)

Il serait également bien si quelqu'un pourrait expliquer comment le JNDI et les talons de travail, d'où vient la coulée se produit (sur le côté client sur le talon, ou sur l'objet original du côté opposé?), Etc.

Merci pour votre aide!

Answer 1

La réponse, malheureusement, est (1).

JNDI ne dicte pas un mécanisme pour la façon dont l'objet est stocké sur l'arbre, ou comment il est livré aux clients. Il est juste une API à utiliser pour effectuer les opérations.

Si les deux applications sont dans la même machine virtuelle Java, car ils sont ici, alors Weblogic est très probable que la remise de l'objet directement à l'application cliente. Il n'y a pas stub, et « côté éloigné ». Étant donné que les types mis en œuvre par cet objet ne sont pas visibles à l'application cliente (rappelez-vous, une identité de type est défini par le nom de la classe, et aussi le classloader il a été chargé).

Vous pourriez penser que c'est une chose étrange de se produire, mais gardez à l'esprit que les applications à parler entre eux comme celui-ci ne sont pas la norme dans le développement JavaEE - les applications sont censés être isolés les uns des autres, ne partageant que les ressources au niveau du système .