Re: [jakartabatch-dev] Overview of Jakarta Batch 2.1 + CDI integration d

[Reza Rahman <reza_rahman@xxxxxxxxx>]

Understand the problem. Personally for now I’ll focus on the platform thread. Hopefully there will be a bit more diverse input there.

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

 

---

From: jakartabatch-dev <jakartabatch-dev-bounces@xxxxxxxxxxx> on behalf of Scott Kurz <skurz@xxxxxxxxxx>
Sent: Tuesday, November 9, 2021 10:15 AM
To: jakartabatch developer discussions
Subject: Re: [jakartabatch-dev] Overview of Jakarta Batch 2.1 + CDI integration details

 

I launched a thread in the Platform dev list: https://www.eclipse.org/lists/jakartaee-platform-dev/msg02929.html

(I know, always tricky to have multiple threads going, so apologies for doing this)

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

"Romain Manni-Bucau" ---11/08/2021 01:27:43 PM---Hi Scott, tried to precise some points inline

From: "Romain Manni-Bucau" <rmannibucau@xxxxxxxxx>
To: "jakartabatch developer discussions" <jakartabatch-dev@xxxxxxxxxxx>
Date: 11/08/2021 01:27 PM
Subject: [EXTERNAL] Re: [jakartabatch-dev] Overview of Jakarta Batch 2.1 + CDI integration details
Sent by: "jakartabatch-dev" <jakartabatch-dev-bounces@xxxxxxxxxxx>

---

Hi Scott,

tried to precise some points inline


Le lun. 8 nov. 2021 à 18:09, Scott Kurz <skurz@xxxxxxxxxx> a écrit :

Thanks Reza,

Let me state here that strictly from the Jakarta Batch spec point of view, I like Romain's approach.    
(Sorry if I seem to be taking the opposite position from before;  I was trying to understand and articulate the case better.)

Although we do have a custom batch-defined lifecycle, the dependent-scoped bean can easily map to the same intuitive lifecycle as the non-bean case (by saying the batch container makes one request to the BeanManager per JSL ref).

I like NOT having to spend our spec resources defining a hybrid, not-quite-CDI-with-custom-rules behavior set within Jakarta Batch.

This result would MOSTLY(*) align with what has already been possible since Batch 1.0, o more or less be formalizing what's known to work.

I'm OK with the user learning curve, e.g. getting past initial "why isn't my injection working?" issues:
There are simple answers for new users:    add @Dependent or set BDM=all.      More sophisticated users will be better served being able to build on their understanding of "just CDI", plus a couple of batch container-provided beans, rather than having to understand the hybrid.

I think my main concern now is the platform...

Bringing up the table: https://github.com/eclipse-ee4j/jakartaee-platform/blob/master/specification/src/main/asciidoc/platform/ResourcesNamingInjection.adoc#a651  again,  
it's clear that the platfrom approach is that you can inject CDI beans into special artifacts defined by the platform spec.    Batch clearly should be in this table here.

Well, all the listed specs are legacy (understand are JavaEE 5 or 6 but were donen in parallel - as not with - of CDI) or close friends of CDI (thinking to interceptors for ex) so it is normal to define a bridge there.

JBatch was created after CDI and embraced CDI upfront - even if not well specified - so no need to add a bridge IMHO and we can keep things simple without loosing any real world use case.

Also don't forget that just enabling an injection in a standalone (not cdi managed) bean will potentially create conflict between both injection mecanisms - for both new users and experimented ones  - and will start to be a nightmare to understand with huge apps whereas keeping them split always lead to a straight forward explanation.

Last point which makes it never needed even if previous sentence didn't convince you: you can always lookup a CDI bean from a standalone instance even if it is not an injection ;). Was not the case for the first release of CDI+spec for the specs of this table, it is now anyway.
 

Should we consider an entry that describes the path we've described above for Batch?

I'm not thinking someone's going to consult this table as doc necessarily.. just more looking to socialize and capture the decision with the rest of the platform, and agree this is a good path forwards.

Thoughts?


(*) We have to sort through the possible change of behavior for impls that did or did not load CDI beans based on ref scheme:  bean name vs. FQCN, like 'jbatch', for example,  but I think this can be resolved independently to the bigger issues above.

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

"jakartabatch-dev" <jakartabatch-dev-bounces@xxxxxxxxxxx> wrote on 11/07/2021 01:38:14 PM:

> From: "Reza Rahman" <reza_rahman@xxxxxxxxx>
> To: "jakartabatch developer discussions" <jakartabatch-dev@xxxxxxxxxxx>
> Date: 11/07/2021 01:38 PM
> Subject: [EXTERNAL] Re: [jakartabatch-dev] Overview of Jakarta Batch
> 2.1 + CDI integration details
> Sent by: "jakartabatch-dev" <jakartabatch-dev-bounces@xxxxxxxxxxx>
>
> Hi Scott,
>
> Sorry for the delay in responding. It has been a hectic few weeks.
>
> It’s been a while since these platform decisions were made back in
> Java EE 6. I will share what I remember and what I have seen in the wild.
>
> The reason the platform went this way for Servlet , JAX-RS, etc is
> because it makes no sense for some components to become full fledged
> CDI beans just to take advantage of injection. As you mention, it’s
> also a cognitive burden for users, many of whom would be confused as
> to why “injection isn’t working”. If this is the case for the Batch
> artifacts in question too, that would be a good case to remain
> consistent with the rest of the platform. It’s also sometimes the
> case that components have their own lifecycle and that collides with
> the CDI container lifecycle.
>
> Hope that helps? I hope I am not too late. To be honest I prefer if
> possible to just try to keep up with the mailing list.
>
> Reza Rahman
> Jakarta EE Ambassador, Author, Blogger, Speaker
>
> Please note views expressed here are my own as an individual
> community member and do not reflect the views of my employer.
>  
>
> From: jakartabatch-dev <jakartabatch-dev-bounces@xxxxxxxxxxx> on
> behalf of Scott Kurz <skurz@xxxxxxxxxx>
> Sent: Thursday, November 4, 2021 10:51 AM
> To: jakartabatch developer discussions
> Subject: Re: [jakartabatch-dev] Overview of Jakarta Batch 2.1 + CDI
> integration details
>  
> Picking up the discussion from the call yesterday with me, Emily
> Jiang, Romain, and Dave Follis.. (please contact me directly if
> you'd like a copy of the recording):
>
>
> The main point of controversy is whether to specify the ability to
> do CDI bean injection into non-bean batch artifacts, as other
> platform specs have done (see the list at:https://github.com/
> eclipse-ee4j/jakartaee-platform/blob/master/specification/src/main/
> asciidoc/platform/ResourcesNamingInjection.adoc#annotations-and-injection)
>
>
> To recap, I had proposed we do specify CDI injection into non-bean
> batch artifacts (like the other specs).
>
> Romain suggested there's no need to support this, arguing the user
> can easily use CDI-defined mechanisms for defining a batch artifact
> as bean: adding a BDA like @Dependent or setting BDM=all, and this
> would lead us down the path of reinventing CDI.
>
> My concerns with Romain's suggestion:
> Yes, the user can easily make a batch artifact a bean (per above),
> but still, maybe we are adding value to the platform by making this
> the default behavior.   It both nudges the user to think in CDI
> terms, highlighting the integration, and also saves them the step of
> adding the BDA like @Dependent (a lesser positive aspect) .  I don't
> see a danger breaking existing apps dependent on running without CDI
> (and they could always configure BDM=none).   In fact, I'm still not
> 100% sure what's wrong with the idea of just saying all Batch
> artifacts are dependent-scoped beans by default (if BDM != 'none)..
> though I think maybe the issue (from an earlier post from Romain) is
> that defining all batch artifacts as beans won't work for us since
> beans need to be known at app startup time?  (So waiting until JSL
> loading is too late?)
> Why, historically, did the other specs (see the platform link)
> decide allowing injection into non-CDI special, spec-specific
> artifacts (e.g. servlets, restful etc.) was a good thing?     What's
> different with Batch?  Are we saying that is now considered a less-
> than-optimal design choice?
> I don't like the thought process that a non-expert user travels
> through.  If you understand anything about the batch lifecycle
> you'll realize @StepScoped more intuitively aligns with the non-CDI
> instance lifecycle.   However, @Dependent works better with batch
> properties..and it happens to also be the default if you use
> BDM=all.     I think this would be worth mastering but is there a
> way to make the learning curve even easier?
>
>
> That said, I'd concede the burden of proof is on me to convince that
> we should do anything here.   Romain's suggestion would be simpler,
> require less invention in the Batch spec, and make it more likely we
> can complete Batch 2.1 on time.  
> All very important, but I still don't want to rush and do the wrong thing.
>
> Given the timeframe, I think too we need to take this to Slack:  
> https://eclipsefoundationhq.slack.com/archives/C02K9FX2ETA  and I'll
> take it on myself to update the mailing list now and then.
>
> Thanks,
> ------------------------------------------------------
> Scott Kurz
> WebSphere / Open Liberty Batch and Developer Experience
> skurz@xxxxxxxxxx
> --------------------------------------------------------
>
> "jakartabatch-dev" <jakartabatch-dev-bounces@xxxxxxxxxxx> wrote on
> 10/21/2021 09:15:32 AM:
>
> > From: "Scott Kurz" <skurz@xxxxxxxxxx>
> > To: "jakartabatch developer discussions" <jakartabatch-dev@xxxxxxxxxxx>
> > Date: 10/21/2021 09:15 AM
> > Subject: [EXTERNAL] Re: [jakartabatch-dev] Overview of Jakarta Batch
> > 2.1 + CDI integration details
> > Sent by: "jakartabatch-dev" <jakartabatch-dev-bounces@xxxxxxxxxxx>
> >
> > Romain,
> >
> > Why don't we work out the details in our Slack channel (#batch in
> > the JakartaEE Development workspace:  https://
> > eclipsefoundationhq.slack.com/archives/C02K9FX2ETA )
> > and then post them here in case anyone wants to join.
> >
> > (No, no one's been missing out on any discussion.. I just created
> > the channel just now).
> >
> > I'd be a bit concerned I lack the CDI background to fully benefit
> > from the call but Emily offered to join to help me out (thank you).
> >
> > ------------------------------------------------------
> > Scott Kurz
> > WebSphere / Open Liberty Batch and Developer Experience
> > skurz@xxxxxxxxxx
> > --------------------------------------------------------
> >
> > [image removed] "Romain Manni-Bucau" ---10/20/2021 02:24:57 PM---
> > Think the goal should be "use beans from cdi if we can find it".
> > Everything else is consequences of
> >
> > From: "Romain Manni-Bucau" <rmannibucau@xxxxxxxxx>
> > To: "jakartabatch developer discussions" <jakartabatch-dev@xxxxxxxxxxx>
> > Date: 10/20/2021 02:24 PM
> > Subject: [EXTERNAL] Re: [jakartabatch-dev] Overview of Jakarta Batch
> > 2.1 + CDI integration details
> > Sent by: "jakartabatch-dev" <jakartabatch-dev-bounces@xxxxxxxxxxx>
> >
> >
> >
> > Think the goal should be "use beans from cdi if we can find it".
> > Everything else is consequences of CDI Bean<> definition:
> >
> > - if scope is compatible batch properties will work, else not (app
> > scoped can under some circumstances get values injected but for the
> > app lifecycle, but this is cdi behavior, no need to redefine
> > anything more than injections are cdi beans too, we must just
> > mention that user must understand it or use dependent scope if he
> isnot sure)
> > - same for scopes, all work while threading compliant (dependent,
> > app scope but request scope has limitations for ex)
> > - interceptors, decorators, specialization etc work
> >
> > Note: interceptors will not work on standalone instance by construction.
> >
> >
> > Now I think we missed two SPI in the spec: JobLoader and
> > ArtifactFactory. First one can need some deeper discussion about the
> > model but last one looks trivial and close to bean validation one
> > It would enable to lookup the batch component in a custom fashion
> > and pass it in batch properties - not stored in db.
> > Default would use cdi lookup - enabling decorators, interceptors,
> > etc...but a plain lambda can be passed in props in standalone too
> > enabling to use spring, guice or any other factory without vendor
> > hack or ambiguity.
> >
> > Side note: we can plan a slack meeting hour next week if it help.
> >
> >
> > Le mer. 20 oct. 2021 à 20:09, Scott Kurz <skurz@xxxxxxxxxx> a écrit :
> > Emily,
> >
> > Thanks for chiming in.   I'm going to merge your post into this
> > single thread and reply.
> >
> > You  wrote:
> >
> > Late to the party... I had some conversation with Scott previously
> > regarding this issue. Let me ask a few questions to see whether I
> > understand the issues.
> >
> > Since you want to inject Batch Artifact to other beans, the batch
> > spec needs to specify Batch Artifacts to be CDI beans (such as Bean
> > Validator providing Validator bean etc). By default, it is Dependent
> > scoped. Are you saying sometimes the artifacts need to be
> > ApplicationScoped? Can ApplicationScoped annotation be added to the
> > Batch Artifact to override the default? My apologies if I understand
> > the conversation wrongly. It might help if Scott can provide a
> > couple of use cases with code snippets.
> >
> >
> > ----
> >
> > Yes, I think in general users should be able to add scope
> > annotations to the batch artifacts... AND the batch container should
> > honor these scopes and load scoped contextual instances when loading
> > artifacts during the batch lifecycle.
> >
> > This maybe isn't quite as useful with @ApplicationScoped (though
> > possibly useful) as it would be with other scoped like @JobScoped/
> > @StepScoped, (now defined only via extension but possibly to be
> > added to the Jakarta Batch spec).  
> > That said,these use cases raise some questions of when/how batch
> > properties should be injected... the values might not be known until
> > job execution time, after app startup.
> >
> > Finally, there was the question of should batch artifacts be treated
> > as (dependent-scoped) beans by default (without the @Dependent
> > annotation)... I was willing to concede "no" as Romain was
> > mentioning startup issues, but still was curious.
> >
> > OK,...possibly some examples are still needed but thread merged at least.
> >
> > ------------------------------------------------------
> > Scott Kurz
> > WebSphere / Open Liberty Batch and Developer Experience
> > skurz@xxxxxxxxxx
> > --------------------------------------------------------
> >
> > "Scott Kurz" ---10/20/2021 01:59:14 PM---Some more comments
> > ------------------------------------------------------
> >
> > From: "Scott Kurz" <skurz@xxxxxxxxxx>
> > To: "jakartabatch developer discussions" <jakartabatch-dev@xxxxxxxxxxx>
> > Date: 10/20/2021 01:59 PM
> > Subject: [EXTERNAL] Re: [jakartabatch-dev] Overview of Jakarta Batch
> > 2.1 + CDI integration details
> > Sent by: "jakartabatch-dev" <jakartabatch-dev-bounces@xxxxxxxxxxx>
> >
> >
> >
> > Some more comments
> > ------------------------------------------------------
> > Scott Kurz
> > WebSphere / Open Liberty Batch and Developer Experience
> > skurz@xxxxxxxxxx
> > --------------------------------------------------------
> >
> > "Romain Manni-Bucau" ---10/14/2021 02:24:10 AM---Le jeu. 14 oct.
> > 2021 à 06:35, Scott Kurz <skurz@xxxxxxxxxx> a écrit : > <SK>
> > Response below detailin
> >
> > From: "Romain Manni-Bucau" <rmannibucau@xxxxxxxxx>
> > To: "jakartabatch developer discussions" <jakartabatch-dev@xxxxxxxxxxx>
> > Date: 10/14/2021 02:24 AM
> > Subject: [EXTERNAL] Re: [jakartabatch-dev] Overview of Jakarta Batch
> > 2.1 + CDI integration details
> > Sent by: "jakartabatch-dev" <jakartabatch-dev-bounces@xxxxxxxxxxx>
> >
> >
> >
> >
> >
> >
> > Le jeu. 14 oct. 2021 à 06:35, Scott Kurz <skurz@xxxxxxxxxx> a écrit :
> > <SK> Response below detailing  new direction:  loading batch
> > artifacts as CDI beans (by default). </SK>
> >
> > ------------------------------------------------------
> > Scott Kurz
> > WebSphere / Open Liberty Batch and Developer Experience
> > skurz@xxxxxxxxxx
> > --------------------------------------------------------
> >
> > "Romain Manni-Bucau" ---10/07/2021 10:09:23 AM---Hi Scott, some
> > comments inline Romain Manni-Bucau
> >
> > From: "Romain Manni-Bucau" <rmannibucau@xxxxxxxxx>
> > To: "jakartabatch developer discussions" <jakartabatch-dev@xxxxxxxxxxx>
> > Date: 10/07/2021 10:09 AM
> > Subject: [EXTERNAL] Re: [jakartabatch-dev] Overview of Jakarta Batch
> > 2.1 + CDI integration details
> > Sent by: "jakartabatch-dev" <jakartabatch-dev-bounces@xxxxxxxxxxx>
> >
> >
> >
> > Hi Scott, some comments inline
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >
> >
> > Le jeu. 7 oct. 2021 à 15:55, Scott Kurz <skurz@xxxxxxxxxx> a écrit :
> > Since Batch + CDI integration overlaps a bunch of issues in our 2.1
> > milestone:  https://github.com/eclipse-ee4j/batch-api/milestone/1 )
> > let me level set with a thread here.
> >
> > My take is that we specify a set of details like this:
> >
> > 1. Batch implementation required to perform CDI injection into batch
> > artifacts  (https://github.com/eclipse-ee4j/batch-api/issues/46)
> >
> > The Batch implementation MUST be able to load batch artifacts and
> > inject CDI-managed beans (i.e. have the CDI engine inject them,
> > however we'd state it), with or without the presence of BDA on the
> > batch artifacts (i.e. without the batch artifacts needing to be
> > themselves loaded as CDI managed beans), unless CDI is disabled
> > altogether,  (e.g. bean discovery mode = none),
> >
> > This loading with CDI bean injection MUST occur for any of the spec-
> > mentioned artifact loading techniques (i.e. mapping from JSL @ref
> > values):  a) CDI bean name(*)  b)   batch.xml entry  c) FQCN     (*)
> > - IIRC, we would need to spec the bean name syntax
> >
> > By default, with BDA=annotated, batch artifacts will not be managed
> > as CDI beans.  
> >
> >
> > Not sure what you meant but annotated will still create cdi beans
> > (as Bean<?>) so it will be compatible, bda=none will ignore the jar
> > so think we should stick to "what is a cdi bean can be a batch
> > component" which also includes producers btw, no?
> >  
> > This will be backed by a statement in the platform spec too (
> > https://github.com/eclipse-ee4j/jakartaee-platform/issues/420),
> >
> >
> > 2.  Instance scope for batch artifacts - CDI bean / non-bean
> >
> > When a batch artifact is loaded but NOT as a CDI-managed bean, the
> > batch implementation MUST ensure artifact instances are scoped to a
> > single JSL reference.   This means, for one, that different methods
> > within a given listener will use the same instance for a given step
> > (e.g. StepListener beforeStep/afterStep).  
> >
> > When a batch artifact is loaded as a CDI-managed bean there should
> > be one instance request (TBD: figure out the correct wording) to the
> > BeanManager for each JSL reference    (This ensures again that
> > using a bean with @Dependent-scoped, the default, doesn't result in
> > different instances across e.g. beforeStep/afterStep).   However,
> > since the BeanManager is control of instance scope it may not be one
> > instance per JSL reference; e.g. using @ApplicationScoped for a
> > batch artifact could result in one instance per application.
> >
> >
> > What about letting the user decide but encourage @Dependent? There
> > are valid cases for @AppScoped (when reusing the same bean and
> > storing the state elsewhere like a request scope bean or jobcontext.
> >  
> >
> > <SK> After thinking some more, what if we just said that every batch
> > artifact is loaded as a CDI bean? (even with  bean discovery mode =
> > annotated, the default)
> >
> > By default, the artifact without any scope annotation would be
> > loaded with @Dependent scope.   So if you tried to inject a batch
> > artifact type into some other bean, by default you'd get a new,
> > separate instance (per @Dependent scope), rather than having to
> > unexpectedly deal with reusing the same instance as the batch
> > container.  (We'd clarify that "loading" happens once per JSL
> > reference, i.e. the batch impl asks the BeanManager for a bean impl
> > once per JSL reference, so e.g. StepListener beforeStep/afterStep
> > use the same instance rather than two instances    )
> >
> > Issue there is some batch component can not be CDI beans so guess
> > the behavior "try to lookup a CDI bean and if none if found, use a
> > plain standalone instance" works well.
> > If we want to make it all CDI beans we must add components as CDI
> > beans at startup which has multiple issues and one is to potentially
> > break the app depending what it does - and we don't control it when embed.
> >
> >
> > Romain, you do have more experience here and so I'm inclined to
> > better trust your preference.
> >
> > I had partly been motivated by the direction being discussed in
> > Jakarta Restful 4.0 to making all Restful classes beans, see:
> > https://www.eclipse.org/lists/jaxrs-dev/msg00974.html 
> > https://github.com/spericas/jaxrs-api/blob/release-4.0/JakartaRest40.pdf 
> >
> > Perhaps it's different though in that they already have annotations
> > like @Path that they can leverage and interpret as bean-defining
> > annotations (though couldn't we achieve something similar by looking
> > at all instance of jakarta.batch.* interface types for artifacts?).
> >
> > But I agree "try to lookup a CDI bean and if none if found, use a
> > plain standalone instance" would work, with the additional
> > requirement that the batch artifacts support contextual CDI
> > injection and interceptors even if the batch artifact isn't itself a
> > bean.  (If you want everything to be a bean you can always use BDM=all).
> >
> > I'm curious though.  How do you think treating all batch artifacts
> > as beans would potentially "break" an application?   (I suppose
> > there is a performance concern maybe, in the cost of scanning, but
> > that's not the concern you mentioned.)
> > ----
> >
> >
> > But this would imply that with say a @StepScoped-annotated batch
> > artifact, anyone injecting an artifact type instance during a step
> > execution will get the same instance created by the batch container
> > (whether we get around to defining @StepScoped in the 2.1 standard
> > or whether it remains only an extension then).
> >
> > Yes, this is one of the reason we should let the user define stating
> > the impact. It is not uncommon to use @ApplicationScoped when the
> > state is 100% hosted by other beans.
> > We should likely make our contexts compatible with that - today
> > think we are dependent so not compatible, no more sure it is state/spec-ed?
> >
> > I'm not sure what you're saying here.   Maybe this overlaps the
> > concern about injecting batch properties???
> >
> >
> > A weird aspect of this scenario, I admit, is that the batch
> > properties may not get injected/populated correctly as defined in
> > JSL.   E.g. if I configure two @JobScoped MyStepListeners but try to
> > define different property sets, well, the CDI instance scope takes
> > precedence and I only get the first one.   Even more strange could
> > be an @ApplicationScoped bean, which might get stuck with 'null'
> > values injected if populated before a job is run (if the bean is
> > loaded that early for some reason).  
> >
> > Right but this is the strength of that too: you can share a state by
> > design between steps.
> > Note that it is the same when you have an endpoint @RequestScoped
> > and inject an @ApplicationScoped inside, think it is ok for CDI users.
> >  
> >
> >
> > I imagine that these types of considerations could lead us down the
> > path of adopting a spec behavior more like Restful services:
> > https://github.com/eclipse-ee4j/jakartaee-platform/blob/master/
> > specification/src/main/asciidoc/platform/ResourcesNamingInjection.adoc#a651
> > where the spec container (servlet/restful container, etc.) manages
> > the component instance, where the component instance can get other
> > CDI beans injected into it, but where the spec container may create
> > an unmanaged instance (so other beans injecting the type of the
> > component instance may end up getting injected with a separate
> > instance created by the CDI container).
> >
> > We are already there actually in 1.0, it is just the root instance
> > which is not so it is more an alignment.
> >  
> > It's true that to some extent ... the integration between Batch +
> > CDI was somewhat "de facto" implied when CDI was present, as in an
> > EE 7 container.  But it was very confusing to say at the same time
> > that CDI was "optional"... (and we've spent many words trying to
> > sort through this).  But yes, in some ways we were already there in 1.0.
> >
> >
> > I guess my intuition though is you will either think injecting a
> > batch artifact into a bean is crazy / overly complicated... or you
> > will want to inject the same exact instance loaded by the batch
> > container.  I don't see what value there'd be in defining a type
> > that serves as a batch artifact (impls that interface) and can also
> > be injected into other beans, using completely separate instances.  
> >
> > Avoiding to define a 3rd bean to get a service, controlling
> > instantitations etc....
> >  
> >
> >
> > Back to the multiple property set issue.. could we instead just have
> > the batch container go set (overwrite) the properties on the
> > instance?   For Job/StepScoped beans, there won't be any other
> > thread using this instance (well, we have to worth through
> > partitions but ignoring that for now).  
> >
> > Not, it must respect the scope so the container provides the
> > properties as a dependent bean, if the scope is compatible it works,
> > else it does not.
> > It is not different from microprofile-config or deltaspike-config
> for example.
> >
> > Are you saying non-dependent scoped beans shouldn't be allowed to
> > inject batch properties?    It seems important to me that Job/Step
> > scoped beans should be allowed to use properties.
> >  
> >
> > OK.. for an ApplicationScoped bean you could have another thread
> > using this but then you probably shouldn't have configured batch
> > properties on it, or they should be immutable.   So only the CDI
> > container creates instances but the batch container still might set
> > values on these instances.
> >
> > And you could disable all this by setting BDM=none and revert to
> > non-CDI, one artifact instance per JSL reference.
> >
> > Or vetoing the bean too.
> >  
> >
> >
> > It would be interesting to hear feedback too from other CDI experts,
> > e.g. those maybe responsible for defining the Restful+CDI instancebehavior.
> > </SK>
> >
> >
> >
> > 3. Inject JobOperator - (straightforward:  https://github.com/
> > eclipse-ee4j/batch-api/issues/17)
> >
> > 4. The Batch implementation MAY provide custom, proprietary
> > techniques for disabling CDI
> >
> > Strictly speaking there's probably no need to explicitly state this
> > but it does provide continuity speaking to our legacy of trying to
> > define a generic, non/pre-CDI specified behavior.  
> >
> > A jakarta.batch.cdi.enabled=false can be neat in properties for portability.
> >
> >  <SK> Though maybe with bean discovery mode = none we already have a
> > standard way to disable CDI, so little need to add another. </SK>
> >
> >
> > There is the embed case where it can help because if you dev a batch
> > as a standalone you can then import it in a jakarta container and
> > there it can become a CDI bean.
> > Generally it will not break anything but behavior will change.
> >
> > That said no big deal to not add it now.
> >
> >
> > 5. (A miscellaneous  consequence worth mentioning) - Don't rely on
> > field initializers  https://github.com/eclipse-ee4j/batch-api/issues/73    
> > Since the CDI engine may be in control of @BatchProperty injection,
> > field initializers can not be relied upon to provide a default value
> > in the absence of a corresponding JSL property, and so should be
> > considered a non-best practice (since CDI is a better practice).
> >
> > I think these artifacts already exist so it's too late to try to ban
> > them.   But we should say something in the spec, since the question
> > has come up.  Perhaps an implementation would want to issue a warning.
> >
> > Think we can say that we register a generic batch property producer
> > with dependent scope so any injection must comply with it. We can
> > also  mention it is only valid during bean lookup (before it is
> > used) and not after clarifying the behavior for normal scope proxies
> > and expliciting the risk for not dependent beans
> >
> > <SK> My concern is if we have an artifact that works in some
> > implementation today which is not using CDI producer to inject batch
> > properties.   With Batch 2.1 and the above proposal since we're
> > saying batch artifacts are beans by default and therefore would have
> > batch property injection handled via a CDI producer.   Maybe the
> > answer here is simply to disable CDI with BDM=none.  This doesn't
> > seem like an "obvious" implication of Batch + CDI spec integration,
> > to me, so I think mentioning in spec could be helpful.  </SK
> >
> > Yes, worse case user can veto all its component through a CDI
> > extension to get back the old behavior during the integration/
> > import. But as an impl there is no way to know it is a warning or
> > not I think.
> >
> >
> > 6. Batch defined custom scope
> >
> > Still on the table:  Job/Step-scoped ((https://github.com/eclipse-
> > ee4j/batch-api/issues/79)    One issue to clarify is whether we
> > should offer both the "thread local" behavior of JobContext/
> > StepContext and non-thread-affinity scope variants, and what exactly
> > to name them, etc.
> > (Not sure if we need to specify when standard CDI scope lifecycle
> > event callbacks are made relative to parts of the batch lifecycle or not)
> >
> > 7. Injection of one Batch artifact into another  https://github.com/
> > eclipse-ee4j/batch-api/issues/171
> >
> > I think we've effectivley covered this now.  Item 2.,  above
> > describes instance creation from the batch container artifact
> > loading, and so at this point we can just say "normal CDI rules
> > apply".  And of course item 6. elaborates on those rules.
> > ---
> >
> > I think that's it.   Did I miss anything?   Appreciate your
> > comments/feedback.
> > ------------------------------------------------------
> > 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
> > _______________________________________________
> > 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[attachment "graycol.gif" deleted
> > by Scott Kurz/Poughkeepsie/IBM] [attachment "graycol.gif" deleted by
> > Scott Kurz/Poughkeepsie/IBM] _______________________________________________
> > 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


_______________________________________________
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