Ошибка JNDI с исключением NameNotFoundException - PullRequest
2 голосов
/ 18 февраля 2009

Я пишу регрессионные тесты для собственной библиотеки (куда давно ушли создатели) и пытаюсь проверить среду. Несколько тестов продолжают терпеть неудачу с этим NameNotFoundException, только когда имя jndi является "сложным".

Это отдельное приложение, которое не работает с веб-контейнерами. Приложение использует файл настроек, и LDAP не задействован. Средой является Java v1.4, и приложение устанавливается со всеми необходимыми локальными библиотеками. (lib dir с jndi.jar, jms.jar ... и т. д.). Просто, верно?

Из-за сложности библиотеки и того, как она работает с большим количеством объектов, у меня есть простой тест, а затем наращиваем сложность, добавляя в каждый фрагмент отдельный тест.

Настройка: Файл: c: \ data \ eclipse \ workspace \ APP \ testfiles \ jndi \ jms \ label \ .bindings
В файле есть эта запись: QReply / FactoryName = com.ibm.mq.jms.MQQueueFactory

Класс UnitTest: «простой» тест имеет

Hashtable ht = new Hashtable();
ht.put(Context.PROVIDER_URL, 
    "file:/data/eclipse/workspace/APP/testFiles/jndi/jms/label/");
ht.put(Context.INITIAL_CONTEXT_FACTORY, 
    "com.sun.jndi.fscontext.RefFSContextFactory");
ht.put(Context.SECURITY_AUTHENTICATION, "none");
Context ctx;
try {
  ctx = new InitialContext(ht);
  String jndiName = "QReply";
  logger.debug("testFindRemoteObject_Simple", 
       "Invoking InitialContext.lookup(\"" + jndiName + "\")");
  Object remoteObject = ctx.lookup(jndiName);
  assertTrue(remoteObject != null);
} catch (NamingException e) {
  e.printStackTrace();
  fail(e.getMessage());
}

Это проходит. Поскольку у меня было так много проблем с библиотекой, я создал другой тест, который соответствует фактическим данным, переданным в; URL-адрес поставщика сокращается, а имя jndi выбирает «путь».

«Фактический» блок данных теста:

final Hashtable ht = new Hashtable();
ht.put(Context.PROVIDER_URL, 
   "file:/data/eclipse/workspace/APP/testFiles/jndi/");
ht.put(Context.INITIAL_CONTEXT_FACTORY, 
   "com.sun.jndi.fscontext.RefFSContextFactory");
ht.put(Context.SECURITY_AUTHENTICATION, "none");
Context ctx;
try {
  ctx = new InitialContext(ht);
  String jndiName = "jms/label/QReply";
  logger.debug("testFindRemoteObject_Actual", 
           "Invoking InitialContext.lookup(\"" + jndiName + "\")");
  Object remoteObject = ctx.lookup(jndiName);
  assertTrue(remoteObject != null);
} catch (NamingException e) {
  e.printStackTrace();
  fail(e.getMessage());
}

Что не получается с

javax.naming.NameNotFoundException: jms/label/QReply
at com.sun.jndi.fscontext.RefFSContext.getObjectFromBindings(
      RefFSContext.java:400)
at com.sun.jndi.fscontext.RefFSContext.lookupObject(RefFSContext.java:327)
at com.sun.jndi.fscontext.RefFSContext.lookup(RefFSContext.java:146)
at com.sun.jndi.fscontext.FSContext.lookup(FSContext.java:127)
at javax.naming.InitialContext.lookup(InitialContext.java:347)
at com.advo.tests.services.UnitTestServiceLocator.testFindRemoteObject_Actual(
           UnitTestServiceLocator.java:85)

где UnitTestServiceLocator.java:85 - это строка ctx.lookup (jndiname);

Почему простой тест пройден, но более сложный тест не пройден? Оба используют classpath, который указывает на каталог lib, который заполнен jms и mq jars (среди прочего).

Сложный тест соответствует тому, что будет заполнять библиотека, но используя магию в качестве переданных значений. В коде библиотеки есть «несколько» строк, которые извлекают магические значения из файла (ов) настроек. Что мне не хватает? Код библиотеки будет работать на сервере, но не работать на моем ноутбуке (при разработке).

Я даже создал другой путь jndi - на случай, если первый тест испортит второй. По-прежнему не удается.

Поскольку у меня нет никакого желания (или разрешения изменять код библиотеки), вызов InitialContext (X); именно так, потому что именно так это делает библиотека. Я видел другие примеры, где ничего не было передано с InitialContext, и я запутался, почему это лучше.

UPDATE: Я создал проект jndi_test на linux java1.5, и он успешно запускает провальный тест. Взяв тот же источник и переместив его в среду Windows - тест не пройден. В пути к классам есть несколько изменений из-за того, что в Linux нет диска C, но файлы данных совпадают. (хмм вопрос с разделителем?)

Я также узнал, что у меня проблемы с этой библиотекой, если я собираюсь запустить ее на 1.5, но это побочная проблема.

1 Ответ

0 голосов
/ 19 февраля 2009

Я думаю, вы путаетесь с именами JNDI.

«QReply» - это имя JNDI. Вы даже говорите так:

В файле есть эта запись: QReply / FactoryName = com.ibm.mq.jms.MQQueueFactory

Если запись была: "jms / label / QReply", тогда ваш второй тест будет работать.

...