Wildfly Невозможно ввести значение?

Question

Я пытаюсь получить закрытый закрытый кеш-фильтр для работы на сервере wildfly.

Вот трассировки стека я получаю:

2016-03-03 15:57:20,909 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 58) MSC000001: Failed to start service jboss.ra.deployer."eclsconnector.rar": org.jboss.msc.service.StartException in service jboss.ra.deployer."eclsconnector.rar": JBAS010446: Failed to start RA deployment [eclsconnector.rar] 
    at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService$1.run(ResourceAdapterDeploymentService.java:157) 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_51] 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_51] 
    at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_51] 
    at org.jboss.threads.JBossThread.run(JBossThread.java:122) 
Caused by: org.jboss.jca.deployers.common.DeployException: IJ020060: Unable to inject: com.empolis.ecls.server.j2ee.jca.impl.ECLSManagedConnectionFactory property: ECLSPropFile value: /app/CMS/modules/server/config/properties/ecls.prop.jboss 
    at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2038) [ironjacamar-deployers-common-1.1.5.Final.jar:1.1.5.Final] 
    at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:1173) [ironjacamar-deployers-common-1.1.5.Final.jar:1.1.5.Final] 
    at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService$AS7RaDeployer.doDeploy(ResourceAdapterDeploymentService.java:209) 
    at org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterDeploymentService.start(ResourceAdapterDeploymentService.java:118) 
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) 
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_51] 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_51] 
    at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_51] 

Что это значит исключение? В каких файлах я должен искать и что я должен попытаться исправить? Нужно ли что-то декомпилировать, модифицировать и перекомпилировать, или это указывает на то, что я неправильно настроил Wildfly?

Извините за редкие детали. Если вы сообщите мне, какие файлы будут полезны для меня, я могу их предоставить. Это просто большой проект, и в первый раз я работал с wildfly, поэтому не знаю, с чего начать.

Answer 1

Когда у вас возникла эта проблема, вам следует настроить Byteman.

Это влечет за собой загрузку и установку его отсюда: http://byteman.jboss.org/, а затем добавить следующую строку в ваш java_opts:

-javaagent:/path/to/byteman.jar=script:/path/to/bytemanRules.btm,boot:/path/to/byteman.jar,listener:true 

Заменить два места, где он говорит /path/to/byteman.jar с пути к вашему Байтмен банку и одно место, где он говорит /path/to/bytemanRules.btm с указанием пути к вашему фактическому файлу правил.

Если у вас была трассировка стека, как у меня, то место, где можно начать с byteman, будет ECLSManagedConnectionFactory.setECLSPropFile - добавьте правила вокруг этого, чтобы он регистрировался в файл, когда он вводит, выходит или бросает этот метод. Следующим шагом будет декомпиляция этого класса.

Найти файл класса (файлы jar/war/ear/rar - это всего лишь zip-файлы - легко открыть), а затем декомпилировать его. IntelliJ имеет встроенный декомпилятор. Используйте декомпилированный класс, чтобы выяснить, какие методы он вызывает. Вернемся в byteman, добавьте правила, основанные на методах, которые вы видите, которые он вызывает (используйте AT INVOKE и AFTER INVOKE), чтобы выяснить, куда он идет и застревает.

Последний полезный вопрос: добавьте -verbose:class к вашему java_opts. Это заставляет Java выплевывать полный путь к каждой баночке, которую он загружает, вместе с классами, которые он нашел в каждой банке.

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

Я не могу дать более конкретную помощь, но, надеюсь, этот короткий список инструментов и методов дает вам полезное исходное место для отладки этой проблемы, а другие с Wildfly (или даже Java вообще ... ничего здесь не является конкретным к Wildfly.)