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
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

Back to the top