Precisa de ajuda para entender o JNDI e uma determinada ClassCastException no J2EE
-
23-09-2019 - |
Pergunta
Eu tenho um aplicativo corporativo A e B implantado (no WLS 10.0). A é a "estrutura", B é um aplicativo cliente. O cliente emite as seguintes chamadas:
Object o = ctx.lookup(jndiName); // line 1
cf = (ConnectionFactory) o; // line 2
ConnectionFactory é uma interface, definida como:
public interface ConnectionFactory
extends java.io.Serializable, javax.resource.Referenceable {
...
}
O que acontece é:
- Se o frasco que contém a classe de interface estiver no sistema de classe do sistema, a linha 2 será executada bem
- Se a classe de interface não estiver no System ClassPath, mas embalada com os aplicativos separadamente, a linha 2 lança uma classe ClassCexception (que tem o texto informativo de que o O é um ConnectionFactoryImpl)
Por que isso é possível? Suponho que a pesquisa JNDI retorne apenas um stub para o objeto remoto (estou certo neste ponto?), Por que importa se o carregador de classe da classe de interface é diferente?
O tipo de resposta que espero:
- Sim, isso deve acontecer da maneira que você experimenta, porque ...
- Não, isso não deve acontecer dessa maneira, porque se ... então ..., então há algo suspeito na sua configuração
- A situação que você descreveu é muito estranha, tem certeza de que não perde algum ponto em algum lugar?
- ... :)
Também seria bom se alguém pudesse esclarecer como o JNDI e os stubs funcionam, onde acontece o elenco (no lado do cliente no stub? Ou no objeto original no lado remoto?), Etc.
Obrigado pela ajuda!
Solução
A resposta, infelizmente, é (1).
O JNDI não dita um mecanismo de como o objeto é armazenado na árvore ou como é entregue aos clientes. É apenas uma API usar para executar as operações.
Se ambos os aplicativos estiverem na mesma JVM, como estão aqui, então o WebLogic provavelmente está apenas entregando o objeto diretamente ao aplicativo cliente. Não há stub e "lado remoto". Como os tipos implementados por esse objeto não são visíveis para o aplicativo cliente (lembre -se, uma identidade de tipo é definida pelo nome da classe e também pelo carregador de classe de onde foi carregado).
Você pode pensar que isso é uma coisa estranha a acontecer, mas lembre -se de que os aplicativos que falam entre si assim não é a norma no desenvolvimento de Javaee - os aplicativos devem ser isolados um do outro, compartilhando apenas recursos no nível do sistema.