Can' t инициализируют Обслуживание в Интеграционном тесте Чаш Грааля из-за поиска JNDI

У меня есть обслуживание, которое осуществляет InitializingBean и DisposableBean

class MyService implements InitializingBean, DisposableBean {

    static transactional = false

    def grailsApplication

    @Override
    void afterPropertiesSet() {
        System.setProperty("JMS_TIMEOUT", grailsApplication.config.JMS_TIMEOUT);
       //code performing a JDNI lookup
    }
}
enter code here

Системные свойства используются, чтобы инициализировать некоторые другие компоненты в обслуживании. Я добавил конфигурации в Config.groovy.

grails.config.locations = [ "file:${basedir}/grails-app/conf/myconfig.properties" ]

Это хорошо работает, запуская приложение. Однако, я пишу интеграционный тест в тесте/интеграции, который вводит обслуживание.

class MyServiceIntegrationTests  extends GrailsUnitTestCase {

   def myService

   void testMyService() {

   }
}

Запуская тест я получаю StackTrace со следующей первопричиной:

Caused by: javax.naming.NameNotFoundException: Name [ConnectionFactory] not bound; 0 bindings: []
at javax.naming.InitialContext.lookup(InitialContext.java:354)
at com.ubs.ecredit.common.jmsclient.DefaultConnector.(DefaultConnector.java:36)

Кажется, что Конфигурация не могла быть загружена или отличается в Интеграционных тестах. Какая-либо идея, как я могу изменить конфигурацию или код, так, чтобы эти свойства были также установлены для моего интеграционного теста перед обслуживанием, иллюстрируется примерами?

UPDATE: It turned out the cause was not the configurations but a JDNI lookup and a bug in Grails. See: http://jira.grails.org/browse/GRAILS-5726

0
nl ja de
Та конфигурация помещается в определенном блоке окружающей среды, или действительно ли это глобально?
добавлено автор Gregg, источник
конфигурация помещается в первую линию моего Config.groovy, таким образом, я предполагаю it' s глобальный.
добавлено автор Will, источник

2 ответы

${basedir} gets different paths in different environments. As an alternative, you can use PropertiesLoaderUtils.loadProperties to load your customized configurations:

import org.springframework.core.io.support.PropertiesLoaderUtils
import org.springframework.core.io.ClassPathResource
....
void afterPropertiesSet() {
    def configProperties = PropertiesLoaderUtils.loadProperties(
                   new ClassPathResource("myconfig.properties"))
    System.setProperty("JMS_TIMEOUT", configProperties.getProperty("JMS_TIMEOUT"))
    ....
}
1
добавлено
@will кажется, что $ {base.dir} является все еще тем же самым в интеграционных тестах, но в производственной среде это пустое. Да, можно поместить другие .properties файлы там.
добавлено автор coderLMN, источник
Регистрация вашего тестового кода может быть полезной.
добавлено автор coderLMN, источник
Где был бы $ {basedir} указывать на для интеграционных тестов? Я мог поместить другой .properties файл туда, правильно?
добавлено автор Will, источник
Если it' s все еще то же самое в интеграционных тестах, почему это потерпело бы неудачу в моем интеграционном тесте тогда?
добавлено автор Will, источник
There' s действительно не много, чтобы добавить. Мой тестовый код может быть, посмотрите в MyServiceIntegrationTests выше. Мой метод тестирования может быть пустым, и ошибка все еще остается, как это происходит, инициализируя обслуживание, которое я предполагаю.
добавлено автор Will, источник
Оказалось, что причиной был поиск JNDI, используемый методом библиотеки, я не показал в afterPropertiesSet() в моем Обслуживании... То, что вы говорили, было правильно. Извините за то, чтобы указывать на неправильное направление. Я отредактирую свой титул вопроса и добавлю новый ответ.
добавлено автор Will, источник

Оказалось, что причиной был поиск JNDI, используемый методом библиотеки, я не показал в afterPropertiesSet() в моем Обслуживании, которое может быть замечено в StackTrace.

After doing some research I found that this was a bug in Grails: http://jira.grails.org/browse/GRAILS-5726

Добавление упомянутой работы, решенной вопрос на данный момент.

0
добавлено
pro.jvm
pro.jvm
3 503 участник(ов)

Сообщество разработчиков Java Scala Kotlin Groovy Clojure Чат для нач-их: @javastart Наш сайт: projvm.com projvm.ru Наш канал: @proJVM Вакансии: @jvmjobs Конфы: @jvmconf

Ruby, Rails, Hanami | dry-rb
Ruby, Rails, Hanami | dry-rb
1 180 участник(ов)

https://telegram.me/rubyjob - Ruby Job По вопросам - @eugene_shved

Rubyata
Rubyata
333 участник(ов)

Коммюнити Ruby и Ruby On Rails Флуд не приветствуются. Вакансии можно публиковать только и ТОЛЬКО по пятницам с хештегом #вакансия.

Rails Chat
Rails Chat
87 участник(ов)

You are welcome to discuss Ruby On Rails development process and other stuff