Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartabatch-dev] CDI based job instantiation

It's a grey area of the JSR 352 spec which says an impl can define whatever mechanism it wants here.

At some point, on Open Liberty, we also added support for loading FQCN as a managed bean though I don't think the original jbatch RI did.

But in any case, it'd be a good thing to clarify moving forwards.

------------------------------------------------------
Scott Kurz
WebSphere Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

Inactive hide details for Romain Manni-Bucau ---02/12/2020 08:06:16 AM---@Martijn can also be a bug in jberet, we commonly use Romain Manni-Bucau ---02/12/2020 08:06:16 AM---@Martijn can also be a bug in jberet, we commonly use that in batchee and never saw any issue (

From: Romain Manni-Bucau <rmannibucau@xxxxxxxxx>
To: jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
Date: 02/12/2020 08:06 AM
Subject: [EXTERNAL] Re: [jakartabatch-dev] CDI based job instantiation
Sent by: jakartabatch-dev-bounces@xxxxxxxxxxx




@Martijn can also be a bug in jberet, we commonly use that in batchee and never saw any issue (https://github.com/rmannibucau/financial-batch/blob/master/src/main/java/com/supertribe/sample/financial/batch/io/DownloadFile.java#L12 and https://github.com/rmannibucau/financial-batch/blob/master/src/main/resources/META-INF/batch-jobs/file-to-database.xml#L10)

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book


Le mer. 12 févr. 2020 à 13:49, Martijn Dashorst <martijn.dashorst@xxxxxxxxx> a écrit :
    I fixed the problem ultimately by modifying my example-job.xml, as the <step ref=""> contained the fully qualified class name of the batchlet, not the CDI name (exampleJob). The CDI based lookup failed, as it doesn't recognize the FQCN of the ExampleJob as a bean (shouldn't that be a featurebug in CDI?), so the JBeret factory did the next thing and instantiate the batchlet itself, and only injecting the JobContext and StepContext beans.

    Not sure if this is my lack of reading the specification, or if this is a lack of examples, or a lack of my understanding. However, it feels a lot like you have to be very lucky to get this right the first time around before you can get productive with Jakarta Batch.

    Martijn



    On Tue, Feb 11, 2020 at 5:46 PM Romain Manni-Bucau <rmannibucau@xxxxxxxxx> wrote:
    Hi Martijn,

    To complete Scott answer, a good practise is to use a beans.xml with CDI containing at least (or adjusted if you are on an older container impl):

    <beans bean-discovery-mode="all" version="2.0"
    xmlns="http://xmlns.jcp.org/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
    http://xmlns.jcp.org/xml/ns/javaee
    http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd">
    <trim/>
    </beans>

    This will enable all beans to be scanned (@Dependent or not compared to annotated mode Scott spoke about). Then the container must honor the CDI bean injections.

    Last note is that the bean module/jar and the batch module/jar (if different) must comply to this rule to ensure both can work portably (theorically the jbatch module does not need since container can inject CDI beans in an unmanaged bean but I don't think it is clearly stated what happens in an unmanaged batch module in general).

    Romain Manni-Bucau
    @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book


    Le mar. 11 févr. 2020 à 16:00, Scott Kurz <skurz@xxxxxxxxxx> a écrit :
      Not sure what CDI mode you're using, but in Open Liberty, at least, you'd typically need to add a bean-defining annotation like @Dependent since batch artifacts aren't "specially" scanned automatically.
      Wouldn't be surprised if JBeret is the same.

      And yes, @Dependent is a bit weird since batch defines its own lifecycle for artifacts.. but CDI does fit in in a bit of a unique way.

      ------------------------------------------------------
      Scott Kurz
      WebSphere Batch and Developer Experience
      skurz@xxxxxxxxxx
      --------------------------------------------------------

      Inactive hide details for Martijn Dashorst ---02/11/2020 09:44:12 AM---All, Not sure if this is the right list, but given my cuMartijn Dashorst ---02/11/2020 09:44:12 AM---All, Not sure if this is the right list, but given my current experience, a

      From:       Martijn Dashorst <martijn.dashorst@xxxxxxxxx>
      To:       jakartabatch-dev@xxxxxxxxxxx
      Date:       02/11/2020 09:44 AM
      Subject:       [EXTERNAL] [jakartabatch-dev] CDI based job instantiation
      Sent by:       jakartabatch-dev-bounces@xxxxxxxxxxx



      All,

      Not sure if this is the right list, but given my current experience, a batch job has some but not all capabilities of CDI injection at its disposal.

      @Named
      public class ExampleBatchlet extends AbstractBatchlet {
          @Inject
          private ExampleService service;

          @Override
          public String process() {
              service.doSomething(); // <-- NullPointerException
          }
      }

      @ApplicationScoped
      public class ExampleService {
          public void doSomething() {}
      }

      This should IMO work, but my Jakarta Batch implementation, jberet, only injects artifacts that are JobContext, StepContext or BatchProperty [1]. 

      Now this can be a bug in JBeret, or a bug in the specification, where it doesn't explicitly require full injectability of CDI beans. (The factory also doesn't take into account setter and constructor based injection).

      Martijn


      [1] https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/creation/AbstractArtifactFactory.java#L67
      --
      Become a Wicket expert, learn from the best: http://wicketinaction.com_______________________________________________
      jakartabatch-dev mailing list
      jakartabatch-dev@xxxxxxxxxxx
      To change your delivery options, retrieve your password, or unsubscribe from this list, visit
      https://www.eclipse.org/mailman/listinfo/jakartabatch-dev



      _______________________________________________
      jakartabatch-dev mailing list
      jakartabatch-dev@xxxxxxxxxxx
      To change your delivery options, retrieve your password, or unsubscribe from this list, visit
      https://www.eclipse.org/mailman/listinfo/jakartabatch-dev
    _______________________________________________
    jakartabatch-dev mailing list
    jakartabatch-dev@xxxxxxxxxxx
    To change your delivery options, retrieve your password, or unsubscribe from this list, visit
    https://www.eclipse.org/mailman/listinfo/jakartabatch-dev


    --
    Become a Wicket expert, learn from the best: http://wicketinaction.com
    _______________________________________________
    jakartabatch-dev mailing list
    jakartabatch-dev@xxxxxxxxxxx
    To change your delivery options, retrieve your password, or unsubscribe from this list, visit
    https://www.eclipse.org/mailman/listinfo/jakartabatch-dev_______________________________________________
    jakartabatch-dev mailing list
    jakartabatch-dev@xxxxxxxxxxx
    To change your delivery options, retrieve your password, or unsubscribe from this list, visit
    https://www.eclipse.org/mailman/listinfo/jakartabatch-dev



Back to the top