Нужна помощь в понимании JNDI и особой ClassCastException в J2EE - PullRequest
3 голосов
/ 28 января 2010

У меня развернуты корпоративные приложения 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. Если банка, содержащая класс интерфейса, находится в системном пути к классам, строка 2 выполняется нормально
  2. Если интерфейсный класс находится не в системном пути к классам, а упакован вместе с приложениями отдельно, в строке 2 выдается исключение ClassCastException (в котором содержится информативный текст о том, что o является ConnectionFactoryImpl)

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

Какой ответ я ожидаю:

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

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

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

1 Ответ

2 голосов
/ 28 января 2010

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...