JSR 352 Как сохранить объект (java.lang.Object) в качестве свойства job?

Question

В JSR352 1,0 Final §9.3 Batch Properties свойства партии определяется как тип java.lang.String:

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

И вот пример:

Properties jobProps = new Properties(); 
jobProps.setProperty("props1", "value1"); 
jobProps.setProperty("props2", "value2"); 

// start 
jobOperator.start("myjob", jobProps); 

Однако, мне нужно использовать другие объекты для работы. Это общее «свойство» может быть любым типом объекта, поэтому java.lang.Object. Поэтому я ищу для работы вокруг решения, которое удовлетворяет следующим условиям:

• Свойство хранится должно быть неизменным, это означает, что когда-то передается в пакетном режиме исполнения, он не будет изменен снова.
• Свойство должно сохраняться при прекращении работы и может быть повторно использовано при перезапуске задания. (Serializable?)
• Решение для рабочего процесса не должно зависеть от какой-либо реализации, например. JBeret от JBoss. Потому что я разрабатываю фреймворк, который позволяет пользователю выбирать собственную реализацию JSR 352.

Может ли кто-нибудь помочь?

Answer 1

Вот идея, которую я имел в виду для вашего прецедента (даже если это похоже на обходной путь).

Вы можете заполнить постоянный объект на протяжении всего жизненного цикла экземпляра задания (т.е. через перезагрузки), введя один или несколько параметров задания в виде пакетных свойств начального шага, а затем используя постоянные пользовательские данные этого начального шага с помощью шага, настроенного с allow-start-if-complete="true", чтобы гарантировать, что шаг всегда выполняется.

---

Подробно:

JobOperator интерфейс только позволяет передавать параметры задание к пакетному приложению в виде единого java.util.Properties объекта.

Так что да, если работаете обойти это ограничение, используя какое-либо приложение или другой контекст (как CDI будет предоставлять) не является хорошим вариантом, то вы должны были бы сделать что-то вроде сериализации Serializable (или маршала а, JAXB) и установить его как параметр задания.

Так что, считая, что вы собираетесь сериализовать свойство с именем serializedObj, будет ли работа выглядеть так, чтобы определить объект уровня работы, который является постоянным и неизменным?

Начните с "настройки" шаг, как это:

<step id="setup" next="step1" allow-start-if-complete="true"> 
    <batchlet ref="SetupBatchlet"> 
     <properties> 
      <property name="serializedObj" value="#{jobParameters['serializedObj']}" /> 
     </properties> 

с реализацией:

public class SetupBatchlet implements Batchlet, BonusPayoutConstants { 

    @Inject 
    @BatchProperty(name = "serializedObj") 
    private String serializedObjStr; 

    @Inject 
    private JobContext jobCtx; 

    @Inject 
    private StepContext stepCtx; 

    @Override 
    public String process() throws Exception { 

     // 1. See if step persistent user data already exists 
     MyObject myObj = (MyObject) stepCtx.getPersistentUserData(); 

     // 2. If not, deserialize 
     if (myObj == null) { 
      myObj = ... // deserialize "serializedObjStr" 
      // 2a. Persist user data 
      stepCtx.setPersistentUserData(myObj); 
     } 

     // 3. set for use by later steps 
     jobCtx.setTransientUserData(myObj); 

и теперь step1 и более поздние стадии могут сделать:

MyObject myObj = (MyObject) jobCtx.getTransientUserData(); 

Так это MyObject экземпляр постоянный и неизменный. Конфигурация allow-start-if-complete="true" гарантирует, что шаг «setup» всегда выполняется, а JobContext всегда заполняется.

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