Ошибка JNDI с исключением NameNotFoundException

Question

Я пишу регрессионные тесты для внутренней библиотеки (куда давно ушли создатели) и пытаюсь проверить среду. Пара тестов продолжает терпеть неудачу с этим 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, и я не понимаю, почему это лучше.

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

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

Answer 1

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

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

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

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