Есть ли способ изменить расположение ObjectStore и PutObjectStoreDirHere при включении JTA на Helidon MP?

Хотелось бы узнать, как настроить расположение ObjectStore за JTA. Моя цель - Helidon MP. В настоящее время каталоги с названием "ObjectStore" а также "PutObjectStoreDirHere"автоматически создаются в текущем каталоге. Также я хотел бы убедиться, действительно ли нам нужны два каталога для управления транзакциями.

Источник

3 ответа

Эти имена каталогов являются именами по умолчанию для определенных каталогов, предоставляемых механизмом транзакций Narayana, который лежит в основе поддержки JTA Helidon.

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

Теперь, как это заполняется? Опять же, глядя на исходный код Нараяны, кажется, что этот экземпляр будет заполнен посредством чего-то, называемого BeanPopulator. В частности,BeanPopulator получит набор свойств по умолчанию, а затем применит их к компоненту в конфигурации -ObjectStoreEnvironmentBean в этом случае - и это предоставит имя каталога хранилища объектов (среди прочего).

Хорошо, но откуда взялись эти свойства? Похоже, что набор свойств по умолчанию находится (в конечном итоге) в AbstractPropertiesFactory класс. В частности, его initDefaultPropertiesметод будет искать XML - файл определенного вида и загрузить его.

Какой XML-файл он будет искать? Похоже, что есть системное свойство с именемcom.arjuna.ats.arjuna.common.propertiesFile, который разрешает путь к рассматриваемому XML-файлу, он будет использован. Если такого свойства System нет, то мы видим, что возвращаемое значение изConfigurationInfo#getPropertiesFile() вместо этого используется.

Как ни странно, во время сборки Narayana (!) Байт-код этого метода заменяется (!) На рецепт, взятый изpom.xml, и, наконец, мы можем увидеть наш ответ: возвращаемое значение этого метода будет, в точности, jbossts-properties.xml.

Это, конечно, какой-то относительный путь или, возможно, ресурс пути к классам. Что это? Для этого мы должны вернуться кAbstractPropertiesFactoryclass и обратите внимание, как используется это имя. Мы видим, что его ищут в разных местах черезFileLocator#locateFile()метод. В FileLocator#locateFile()метод сначала пытается обработать имя как абсолютный путь (очевидно, мы можем видеть, чтоjbossts-properties.xmlне является абсолютным путем), то как путь относительноuser.dir, user.home а также java.homeСистемные свойства в этом порядке (почти наверняка он тоже не будет существовать) и, наконец, как ресурс пути к классам. Итак, вот наш ответ:jbossts-properties.xml, если он присутствует в качестве ресурса пути к классам, будет использоваться как источник, в котором Нараяна должен создать и разместить каталог хранилища объектов.

Итак, как выглядит этот XML-файл? Похоже, что пример файла можно найти здесь: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/narayana-jta/src/main/resources/jbossts-properties.xml. Вы можете видеть, что что-то вроде этого в конечном итогеPutObjectStoreDirHereисходит из. Поэтому я думаю, что если вы установите один из них в одном из мест, описанных выше, вы можете разместить хранилище объектов в любом месте, где захотите.

Однако все становится немного странно, потому что пока это отвечает на вопрос о том, где PutObjectStoreDirHereисходит, по- видимому, не отвечает на вопрос, где простоObjectStoreпроисходит от. Мы видим, что это значение по умолчанию дляobjectStoreDirbean свойство, если мы посмотрим на исходный кодObjectStoreEnvironmentBeanопять же, поэтому я предполагаю, что здесь может быть какое-то другое свойство.

Как упоминалось ранее, я не эксперт по Нараяне, поэтому, возможно, будет лучше связаться с людьми Нараяны, чтобы узнать здесь все подробности обо всех крайних случаях.

Источник

Согласно документации Нараяны , вы можете установить одно из следующих системных свойств.

  1. ObjectStoreEnvironmentBean.objectStoreDir
  2. ObjectStoreEnvironmentBean.localOSRoot

как в

      java -DObjectStoreEnvironmentBean.objectStoreDir=/tmp/whatever -jar my-helidon-mp-thing-that-cant-tell-jpa-and-jta-apart.jar

Но это действительно перемещает только каталог «PutObjectStoreDirHere». Каталог "ObjectStore" жестко запрограммирован в Нараяне на это:

частный изменчивый String objectStoreDir = System.getProperty ("user.dir") + File.separator + "ObjectStore";

И в helidon / CDI нет хорошего способа подключиться к циклу инициализации и вызвать ObjectStoreEnvironmentBean :: setObjectStoreDir, так что нам просто нужно жить с этим.

Для меня более серьезный вопрос заключается в том, почему у нас должна быть какая-то шумная реализация JTA, когда на самом деле все, что кто-то хочет, чтобы @Transaction выполняла, это открывать и закрывать транзакцию. JTA на самом деле не добавляет ценности ни здесь, ни где-либо еще.

Источник

Вы можете установить каталог хранилища объектов, передав приложению эту опцию:

      -Duser.dir=/object-store

Но если есть какие-либо проблемы с текущим хранилищем объектов (например, проблемы с записью файлов/разрешениями), я лично считаю, что лучшим решением будет изменение типа хранилища объектов на другой тип, например энергозависимое хранилище, которое не требует записи в какие-либо файлы. , вы можете сделать это, передав приложению эту опцию:

      -Dcom.arjuna.ats.arjuna.common.ObjectStoreEnvironmentBean.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.TwoPhaseVolatileStore

Вы можете проверить доступные хранилища объектов в исходном коде Нараяны https://github.com/jbosstm/narayana/blob/5.12.0.Final/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/TwoPhaseVolatileStore .Джава

Источник
Другие вопросы по тегам