需要帮助理解JNDI和J2EE中的特定ClassCastException [英] Need help understanding JNDI and a particular ClassCastException in J2EE

查看:152
本文介绍了需要帮助理解JNDI和J2EE中的特定ClassCastException的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我部署了企业应用程序A和B(在WLS 10.0中)。 A是框架,B是客户端应用程序。
客户发出以下电话:

 对象o = ctx.lookup(jndiName); //第1行
cf =(ConnectionFactory)o; //第2行

ConnectionFactory是一个接口,定义为:

 公共接口ConnectionFactory 
扩展java.io.Serializable,javax.resource.Referenceable {
...
}

会发生什么:


  1. 如果包含接口类的jar在系统类路径上,则第2行执行正常

  2. 如果接口类不在系统类路径上,而是与应用程序分开打包,则行2抛出一个ClassCastException(其中包含o是ConnectionFactoryImpl的信息文本)

为什么这可能?我假设JNDI查找只返回一个存根到远程对象(我在这一点上是正确的吗?),那么为什么接口类的类加载器是不同的呢?



我期待的那种答案:


  1. 是的,它应该以您体验的方式发生,因为...

  2. 不,它不应该这样发生,因为如果......那么......,你的设置中有一些可疑的东西

  3. 你的情况描述很奇怪,你确定你不会错过任何地方吗?

  4. ... :)

如果有人能够澄清JNDI和存根如何工作,在哪里进行转换(在存根上的客户端?或者在远程端的原始对象上?)等等,这也会很好。



感谢您的帮助!

解决方案

答案很遗憾,是(1)。



JNDI没有规定对象如何存储在树上的机制,或者如何交付给客户。它只是用于执行操作的API。



如果两个应用程序都在同一个JVM中,就像它们在这里一样,那么Weblogic很可能只是直接处理对象到客户端应用程序。没有存根和远程端。由于该对象实现的类型对客户端应用程序不可见(请记住,类型标识是由类名定义的,也是由它加载的类加载器)。



<你可能认为这是一个奇怪的事情发生,但请记住,应用程序之间的谈话并不是JavaEE开发中的常态 - 应用程序应该彼此隔离,只共享系统级资源。


I have an enterprise application A and B deployed (in WLS 10.0). A is the "framework", B is a client app. The client issues the following calls:

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

ConnectionFactory is an interface, defined as:

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

What happens is:

  1. If the jar containing the interface class is on the system classpath, line 2 is executed fine
  2. If the interface class is not on the system classpath, but packaged with the applications separately, line 2 throws a ClassCastException (which has the informative text that the o is a ConnectionFactoryImpl)

Why is this possible? I assume that the JNDI lookup returns only a stub to the remote object (am I right in this point?), then why does it matter if the classloader of the interface class are different?

The kind of answer I expect:

  1. Yes, it should happen the way you experience it, because ...
  2. No, it should not happen this way, because if ... then ..., so there is something fishy in your setup
  3. The situation you described is very strange, are you sure you don't miss some point somewhere?
  4. ... :)

It would also be nice if someone could clarify how the JNDI and stubs work, where does the casting happen (on the client side on the stub? or on the original object on the remote side?), etc.

Thanks for your help!

解决方案

The answer, sadly, is (1).

JNDI does not dictate a mechanism for how the object is stored on the tree, or how it is delivered to clients. It's just an API to use for performing the operations.

If both applications are in the same JVM, as they are here, then Weblogic is very likely just handing the object directly to the client application. There is no stub, and "remote side". Since the types implemented by that object are not visible to the client application (remember, a type identity is defined by the class name, and also the classloader it was loaded from).

You might think this is a weird thing to happen, but bear in mind that applications talking amongst themselves like this is not the norm in JavaEE development - the apps are supposed to be isolated from one another, sharing only system-level resources.

这篇关于需要帮助理解JNDI和J2EE中的特定ClassCastException的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆