Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartabatch-dev] discussion on JobOperator injection - should runtime provide bean? , extensions, portability, etc.
Hi Scott,

the common pattern is:

@Produces JobOperator op() { return BatchRuntime.getJobOperator(); }

Sometimes with @ApplicationScoped added too.

This is why I think not adding the bean is the simplest and most user friendly solution for end users (avoids a @JBatch qualifier for ex).

In terms of priority it is quite simple: if user did the work it is always higher priority than the default runtime one. If you need more - which is out of spec cause it means multiple beans are in user land - you have CDI to solve it so we are good, simple and safe with it I guess?

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


Le mer. 15 déc. 2021 à 14:44, Scott Kurz <skurz@xxxxxxxxxx> a écrit :

Roberto,

Thanks for your review.   However, I'm not clear which side you're taking...  which probably means I haven't laid out the decision clearly enough.

Romain had suggested https://github.com/eclipse-ee4j/batch-api/pull/183#pullrequestreview-828924368 
specifying the runtime should ONLY register a JobOperator bean if none is present.

I was trying to be a bit more vague, and say the application should expect the runtime to provide one, but wanted to avoid saying anything about the precedence.
I don't think the precedence is easy to specify.   How does a given piece of code know whether it is the "runtime" that should defer to the "application" JobOperator or vice versa?

But from your response, I wonder if you're arguing for Romain's suggestion.

When you say you always include add a JobOperator bean.. do you just have it delegate to BatchRuntime.getJobOperator() ?   Or do you delegate to your specific JobOperator impl (in which case it doesn't sound portable).

Thanks,
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

Inactive hide details for "Roberto Cortez via jakartabatch-dev" ---12/14/2021 07:50:07 PM---I think it is reasonable for implem"Roberto Cortez via jakartabatch-dev" ---12/14/2021 07:50:07 PM---I think it is reasonable for implementations to provide injection for JobOperator if none is present

From: "Roberto Cortez via jakartabatch-dev" <jakartabatch-dev@xxxxxxxxxxx>
To: "jakartabatch developer discussions" <jakartabatch-dev@xxxxxxxxxxx>
Cc: "Roberto Cortez" <radcortez@xxxxxxxxx>
Date: 12/14/2021 07:50 PM
Subject: [EXTERNAL] Re: [jakartabatch-dev] discussion on JobOperator injection - should runtime provide bean? , extensions, portability, etc.
Sent by: "jakartabatch-dev" <jakartabatch-dev-bounces@xxxxxxxxxxx>




I think it is reasonable for implementations to provide injection for JobOperator if none is present. It is likely that a lot of apps out there provide their own produces, I think I always add one every time I use batch :)
    On 13 Dec 2021, at 15:24, Scott Kurz <skurz@xxxxxxxxxx> wrote:

    First, a status update:  

    The spec and TCK have been merged with several CDI integration updates.     Thank you especially to Romain for all the reviews and helpful comments.

    I am very close to releasing a 2.1.0-M1 TCK.     At that point, as impls experiment with the TCK we can go back and see if any of the spec/TCK updates are needed, and discuss more, etc.
    (I'm sure not everyone got to review every line of spec update merged so far... so there's still a chance to make changes).
    ---

    There's only issue we need to discuss though:  injecting JobOperator.

    My general thought was to establish that a runtime should provide a JobOperator while saying as little about the mechanism as possible.

    This mirrors the approach we did for the     BatchRuntime.getJobOperator() API, as we did not specify the extension mechanism here either.
    (Though of course the javax/jakarta Maven artifacts did use     ServiceLoader and so arguably provide a "de facto standard"?)

    So I kept the language vague in the PR:      https://github.com/eclipse-ee4j/batch-api/pull/183 saying no more than that the runtime must provide a JobOperator CDI Bean "if necessary".

    I also added a new TCK test to inject JobOperator into an executing batch artifact (I didn't want to complicate the TCK by some other servlet or managed component type to the test).

    However, Romain pointed out in comments:
         https://github.com/eclipse-ee4j/batch-api/pull/183#issuecomment-991316256
         https://github.com/eclipse-ee4j/batch-api/pull/183#pullrequestreview-828924368

    that this could potentially break an existing user packaging their own JobOperator and suggested we might say something like "the runtime only adds a bean if it detects there is not already one present".

    IMO, we should not detail the precedence or extension mechanism here.... but instead leave this up to vendors/implementations.

    OTOH, I do not think we should remove the requirement altogether.   I think the user should expect that a simple app can be deployed to a runtime that claims batch support and the runtime will have a JobOperator ready for it to inject.

    OK, let me stop and hit send and see what everyone else thinks.

    Thanks,
    ------------------------------------------------------
    Scott Kurz
    WebSphere / Open Liberty Batch and Developer Experience
    skurz@xxxxxxxxxx
    --------------------------------------------------------

    _______________________________________________
    jakartabatch-dev mailing list
    jakartabatch-dev@xxxxxxxxxxx
    To unsubscribe from this list, visit     https://www.eclipse.org/mailman/listinfo/jakartabatch-dev

_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev




_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev

Back to the top