Нужна помощь в понимании JNDI и конкретного исключения ClassCastException в J2EE

У меня развернуто корпоративное приложение A и B (в WLS 10.0). A - это «фреймворк», B - клиентское приложение. Клиент делает следующие звонки:

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

ConnectionFactory - это интерфейс, определяемый как:

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

Что происходит:

  1. Если jar, содержащий класс интерфейса, находится в системном пути к классам, строка 2 выполняется нормально
  2. Если интерфейсный класс не находится в системном пути к классам, но упакован с приложениями отдельно, строка 2 выдает исключение ClassCastException (в котором содержится информативный текст о том, что o является ConnectionFactoryImpl)

Почему это возможно? Я предполагаю, что поиск JNDI возвращает только заглушку для удаленного объекта (я прав в этом вопросе?), Тогда почему это имеет значение, если загрузчик классов интерфейса класса отличается?

Я ожидаю такого ответа:

  1. Да, это должно происходить так, как вы это переживаете, потому что ...
  2. Нет, этого не должно происходить, потому что если ... то ... значит, в вашей настройке есть что-то подозрительное.
  3. Ситуация, которую вы описали, очень странная, вы уверены, что где-то не упустили какой-то момент?
  4. ... :)

Также было бы неплохо, если бы кто-нибудь мог прояснить, как работают JNDI и заглушки, где происходит приведение (на стороне клиента на заглушке? Или на исходном объекте на удаленной стороне?) И т. Д.

Спасибо за вашу помощь!


classloader classcastexception weblogic-10.x jndi jakarta-ee
person ron    schedule 28.01.2010    source источник

Ответы (1)


arrow_upward
2
arrow_downward

К сожалению, ответ (1).

JNDI не диктует механизм того, как объект хранится в дереве или как он доставляется клиентам. Это просто API для выполнения операций.

Если оба приложения находятся в одной JVM, как и здесь, тогда Weblogic, скорее всего, просто передает объект непосредственно клиентскому приложению. Есть не заглушка, а "удаленная сторона". Поскольку типы, реализованные этим объектом, не видны клиентскому приложению (помните, что идентичность типа определяется именем класса, а также загрузчиком классов, из которого он был загружен).

Вы можете подумать, что это может произойти странно, но имейте в виду, что приложения, которые разговаривают между собой подобным образом, не являются нормой в разработке JavaEE - приложения должны быть изолированы друг от друга, разделяя только ресурсы системного уровня.

person skaffman    schedule 28.01.2010
comment
Спасибо за ответ. Что меня смутило, так это то, что Weblogic пишет о EJB, что вызов EJB между приложениями может происходить только через удаленный интерфейс. Я знаю, что это не имеет ничего общего с EJB, но я сделал вывод, что запрос объекта JNDI, находящегося в другом приложении, будет прибегать к подобному удаленному механизму, который тогда не должен быть правдой. - person ron; 28.01.2010
comment
Правильно, да. Когда удаленно доступный EJB публикуется на JNDI, он явно публикует заглушку. - person skaffman; 28.01.2010