Necesita ayuda JNDI comprensión y un ClassCastException particular, en J2EE

Question

I tiene una aplicación de empresa A y B desplegado (en WLS 10.0). Una es el "marco", B es una aplicación de cliente. Los problemas de los clientes las llamadas siguientes:

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

ConnectionFactory es una interfaz, definido como:

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

Lo que ocurre es:

1. Si el frasco que contiene la clase de interfaz está en la ruta de clase del sistema, la línea 2 está bien ejecutado
2. Si la clase de interfaz no está en la ruta de clase del sistema, sino que viene embalado con las aplicaciones por separado, la línea 2 lanza una ClassCastException (que tiene el texto informativo que la junta es un ConnectionFactoryImpl)

¿Por qué es esto posible? Asumo que el JNDI de búsqueda sólo devuelve un código auxiliar al objeto remoto (Estoy en lo correcto en este punto?), Entonces ¿qué importa si el cargador de clase de la clase de interfaz son diferentes?

El tipo de respuesta que esperaba:

1. Sí, esto debe ocurrir de la manera que lo experimenta, porque ...
2. No, debería no sucede así, porque si ... entonces ..., por lo que hay algo raro en su configuración
3. La situación que usted describe es muy extraño, ¿está seguro de que no se pierda algún punto en alguna parte?
4. ...:)

También sería bueno que alguien podría aclarar cómo el trabajo JNDI y talones, donde sucede la fundición (en el lado del cliente en el talón? O en el objeto original en el lado remoto?), Etc.

Gracias por su ayuda!

Answer 1

La respuesta, lamentablemente, es (1).

JNDI no dicte un mecanismo de cómo el objeto se almacena en el árbol, o la forma en que se entrega a los clientes. Es sólo una API para utilizar para realizar las operaciones.

Si ambas aplicaciones se encuentran en la misma JVM, como aquí, entonces es muy probable Weblogic sólo entregar el objeto directamente a la aplicación cliente. No hay ningún trozo, y "lado remoto". Puesto que los tipos implementadas por ese objeto no son visibles a la aplicación cliente (recuerda, una identidad tipo se define por el nombre de la clase, y también el cargador de clases se carga desde).

Se podría pensar que esto es algo raro que suceda, pero hay que tener en cuenta que las aplicaciones que hablan entre sí como esta no es la norma en el desarrollo JavaEE - se supone que las aplicaciones para ser aislados unos de otros, compartiendo sólo los recursos a nivel de sistema .