------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer
Experience
skurz@xxxxxxxxxx
--------------------------------------------------------
"Reza Rahman"
---11/15/2021 08:05:35 PM---I would certainly be
curious to learn a bit more about what the EJB/JSF
point is. To my knowledge, n
From: "Reza Rahman" <reza_rahman@xxxxxxxxx>
To: "jakartaee-platform
developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 11/15/2021 08:05 PM
Subject:
[EXTERNAL] Re:
[jakartaee-platform-dev] Batch+CDI integration:
proposal to continue NOT injecting CDI beans into
non-bean Batch artifacts
Sent
by: "jakartaee-platform-dev"
<jakartaee-platform-dev-bounces@xxxxxxxxxxx>
I would certainly be curious
to learn a bit more about what the EJB/JSF point is. To
my knowledge, neither API had the particular use case in
question.
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: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
on behalf of Scott Kurz <skurz@xxxxxxxxxx>
Sent: Monday,
November 15, 2021 6:55 PM
To: jakartaee-platform
developer discussions
Subject: Re:
[jakartaee-platform-dev] Batch+CDI integration: proposal
to continue NOT injecting CDI beans into non-bean Batch
artifacts
Thanks Ondro,
I'm glad you broadened the discussion to add back the
idea of treating all batch artifacts as beans (your
option 3.).
Though generating a qualifier like `BatchArtifact` could address the problem
of creating a new ambiguous dependency, my biggest
concerns with 3. are Romain's suggestions that we'd be
committing Batch to essentially re-implement CDI
scanning or else end up with inconsistencies.
I'm reacting to these posts:
https://eclipsefoundationhq.slack.com/archives/C02K9FX2ETA/p1636134043025000?thread_ts=1636126456.019800&cid=C02K9FX2ETA
https://eclipsefoundationhq.slack.com/archives/C02K9FX2ETA/p1636127555021000?thread_ts=1636126456.019800&cid=C02K9FX2ETA
and this one suggesting there were some negative
lessons learned with the Enterprise Beans and Server
Faces specs:
https://eclipsefoundationhq.slack.com/archives/C02K9FX2ETA/p1636128063022600?thread_ts=1636126456.019800&cid=C02K9FX2ETA
For what it's worth, another point I'd raised is that
we can't know what batch artifacts will ultimately be
used at application startup, (since we don't know what
jobs will ultimately be executed), so we'd have to do
something type-based like register all jakarta.batch.api.* impls.
But I fully admit not understanding this at the depth
and detail necessary to have a truly informed
opinion.. which is why I was hoping to tap into the
collective wisdom of the platform list here.
Maybe we could ask Romain to elaborate more?
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer
Experience
skurz@xxxxxxxxxx
--------------------------------------------------------
"jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
wrote on 11/10/2021 11:25:51 AM:
> From: "Ondrej Mihályi"
<ondrej.mihalyi@xxxxxxxxxxx>
> To: "jakartaee-platform developer discussions"
<jakartaee-platform-
> dev@xxxxxxxxxxx>
> Date: 11/10/2021 11:26 AM
> Subject: [EXTERNAL] Re:
[jakartaee-platform-dev] Batch+CDI
> integration: proposal to continue NOT injecting
CDI beans into non-
> bean Batch artifacts
> Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
>
> Hi,
>
> I followed the previous conversation and it's
easy to get lost in
> the proposals and arguments so I'll try to
summarize what are the
> proposals and questions/problems related to
them. Scott and others,
> please correct me if I get it wrong.
>
> The 2 options discussed are whether:
> Batch artifacts would not become CDI beans by
default (could be
> turned into CDI beans by a user as nowadays)
but would allow injection
> of CDI artifacts. They wouldn't be injectable
into other CDI beans.
> Similar to how Servlets, REST resources and
other platform beans work now
> Batch artifacts would not become CDI beans and
would not allow injection
> of CDI artifacts. They wouldn't be injectable.
CDI artifacts would
> need to be accessed via CDI.current() mechanism
unless the artifact
> is turned into a CDI bean by a user
> Batch artifacts should become CDI beans by
default and thus allow injecting
> CDI beans into them. This in turn would also
make them injectable
> into other CDI beans
> Summarized:
>
> Option 1: Artifacts not CDI beans, cannot be
injected, other CDI beans can
> be injected into them
> Option 2: Artifacts not CDI beans, cannot be
injected, other CDI beans cannot
> be injected into them (only accessesd via
CDI.current())
> Option 3: Artifacts are CDI beans, can be
injected, other CDI beans can
> be injected into them
>
> It looks like although the option 3 was
mentioned earlier, it's not
> being considered now and we're choosing between
1 and 2.
>
> However, I think that the option number 3 might
be the best as it
> combines best of both:
> CDI clearly defines the lifecycle (e.g. running
PostConstruct
> method) and Batch spec can just build on this
(specify the default
> scope of artifacts, inject Batch context
objects as CDI beans,
> inject not only using field injection but also
support other
> injection mechanisms)
> Batch artifacts could be injected and
intercepted as CDI beans
> automatically, no need to turn them into CDI
beans by the user as
> with solution 2
> Batch spec doesn't need to reinvent the wheel
and just rely on the
> CDI mechanism for injection, so it's much
easier to specify than
> with solution 1
>
> I think I have a good solution for all the
drawbacks of this
> approach mentioned earlier, which I'll explain.
>
> AFAIR, the arguments against option 3 were:
> It could break current applications, because
artifacts, which
> previously weren't CDI beans, could cause
ambiguous dependency
> situations if they would match other existing
beans and injection
> points that only expect a single bean. E.g.
batch artifact B extends
> from a CDI bean A, and some other CDI bean C
injects A. Now, A would
> just be injected to C, while B is not
considered for injection. If B
> is turned into a CDI bean by default, then both
A and B would be
> considered for injection into C -> Ambiguous
> It's possible that a batch artifact class
doesn't meet the
> requirements for CDI and it couldn't be turned
into a CDI bean (for
> example no noarg constructor)
> Batch would rely on CDI to work, even if it's
used outside of a
> Jakarta EE runtime
> Solution for problem 1
>
> I think this can be easily resolved by creating
a new @BatchArtifact
> CDI qualifier in the API and add this qualifier
to all CDI beans
> created from the non-CDI Batch artifacts by the
container. This
> would clearly separate CDI beans created by a
Batch container and
> those created by a user, beans created by the
container wouldn't be
> attempted to inject into user's code. It would
still be possible to
> inject them into other CDI beans using the
qualifier if needed
> (although this is rather edge case). And the
Batch container can
> just use the CDI container directly to
instantiate the beans, again
> using the qualifier. The Batch container would
only need to supply a
> standard CDI extension to create such a CDI
bean for non-CDI artifacts.
>
> Solution for problem 2
>
> This actually isn't a problem at all. In most
cases, classes need to
> have a no-arg constructor so that they can be
instantiated by their
> class name. So this is an edge case. And even
if artifacts can't be
> turned into CDI beans, they could be treated as
they are treated now
> - CDi injection wouldn't work, only simple
non-CDI injection
> specified by the Batch spec already would take
place. CDI beans
> wouldn't be injected. Runtimes can produce a
warning about this and
> suggestion to make the class valid for CDI to
make CDI injection work.
>
> Solution for problem 3
>
> This is similar situation as for problem 2 - if
Batch shouldn't rely
> on CDI, artifacts can't be turned into CDI
beans. Then they would be
> treated as they are treated now, with limited
injection. This is OK
> because CDI isn't available and therefore not
expected to inject beans.
>
> Is there anything wrong in my assumptions? What
could break if we
> implement the option 3 in the way I suggest?
>
> Kind regards,
> Ondrej Mihályi
> Senior Payara Service Engineer
> Payara - Supported Enterprise Software for
Jakarta EE and
> MicroProfile Applications
> US: +1 415 523 0175 | UK: +44 207 754 0481
>
----------------------------------------------------------------------------------------------------------------------
> Payara is a proud recipient of the prestigious
Queen's Award for
> Enterprise: International Trade 2021
> Payara-Tech LDA, Registered Office: Rua Nova de
São Pedro no. 54,
> 2nd floor, room “D”, 9000 048 Funchal, Ilha da
Madeira, Portugal
> VAT: PT 515158674 | www.payara.fish | info@xxxxxxxxxxx | @Payara_Fish
>
> From: jakartaee-platform-dev
<jakartaee-platform-dev-
> bounces@xxxxxxxxxxx>
on behalf of Scott Kurz <skurz@xxxxxxxxxx>
> Sent: 09 November 2021 22:45
> To: jakartaee-platform developer discussions
<jakartaee-platform-
> dev@xxxxxxxxxxx>
> Subject: Re: [jakartaee-platform-dev] Batch+CDI
integration:
> proposal to continue NOT injecting CDI beans
into non-bean Batch artifacts
>
> Thanks Reza,
>
> Yes we're talking about batchlets, listeners,
readers, writers and
> processors: the spec-defined artifacts
analogous to servlets, etc.
> in the table at: https://github.com/eclipse-ee4j/jakartaee-platform/
>
blob/master/specification/src/main/asciidoc/platform/
> ResourcesNamingInjection.adoc#a651
>
> My experience from Batch 1.0 is that users
wanting to inject CDI
> beans were able to figure out, without too much
confusion, that they
> could add a @Dependent on the batch artifact,
or set BDM=all (yes
> the move from CDI 1.0 to 1.1 BDM may have
required some re-learning
> but for all CDI users not Batch especially).
>
> The argument Romain and I are making is that
this is easy enough for
> new/naive users. For more advanced users, it
is preferable to just
> defer to CDI rather than inventing (from the
batch perspective), or
> continuing the pattern (from the platform
perspective) the behavior
> for a hybrid, not-quite-CDI injection into a
non-bean artifact use
> case, and define custom "hybrid" rules.
>
> I do see time constraints as an issue and don't
want to rush.
> However, the proposal now mostly would just
standardize what people
> have been able to do since 2013.
>
> True, at one point I was arguing the opposite
case: to support CDI
> injection into a non-bean batch artifact. I
was taking for
> granted that this was the expected norm that
most would agree on
> when bringing a component spec into the
Platform, and integrating
> with CDI, and a well-known pattern from
integrating other specs.
>
> It does seem late to be defining any new
behavior, though, but
> possibly not too late to ratify existing
behavior, if we can reach
> consensus from both the Batch & Platform
perspectives.
>
> Appreciate you trying to get more feedback,
>
------------------------------------------------------
> Scott Kurz
> WebSphere / Open Liberty Batch and Developer
Experience
> skurz@xxxxxxxxxx
>
--------------------------------------------------------
>
> [image removed] "Reza Rahman" ---11/09/2021
09:59:02 AM---I do hope
> there are other folks still left that can
provide the institutional
> knowledge. If not, may
>
> From: "Reza Rahman" <reza_rahman@xxxxxxxxx>
> To: "jakartaee-platform developer discussions"
<jakartaee-platform-
> dev@xxxxxxxxxxx>
> Date: 11/09/2021 09:59 AM
> Subject: [EXTERNAL] Re:
[jakartaee-platform-dev] Batch+CDI
> integration: proposal to continue NOT injecting
CDI beans into non-
> bean Batch artifacts
> Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
>
>
>
> I do hope there are other folks still left that
can provide the
> institutional knowledge. If not, maybe the
answer is to form that
> institutional knowledge now.
>
> I prefer what I think would be easiest for
users, which would be to
> just support injection by default rather than
needing to convert
> over to CDI beans when needed. That said, I
honestly have not seen
> that need in Bach usage in the wild that much
and in general people
> seem to just make batch artifacts CDI beans
anyway. So maybe in this
> case it’s fine. I may also be missing an
understanding of all the
> cases where injection may be needed. Is it more
than just batchlets,
> listeners, readers, writers and processors? I
think it’s fine to
> expect those will probably be CDI beans, that’s
what I have seen
> most people do anyway.
>
> If part of the issue is time constraints before
the next release, is
> it better to just leave options open until we
can get more Batch end
> user input? It’s surprising so few people have
chimed in so far.
> I’ll try to see if I can change that.
>
> 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: jakartaee-platform-dev
<jakartaee-platform-dev-
> bounces@xxxxxxxxxxx>
on behalf of Scott Kurz <skurz@xxxxxxxxxx>
> Sent: Tuesday, November 9, 2021 9:37 AM
> To: jakartaee-platform-dev
> Subject: [jakartaee-platform-dev] Batch+CDI
integration: proposal to
> continue NOT injecting CDI beans into non-bean
Batch artifacts
>
> Hi,
>
> I wanted to get some Platform-level input for
the discussion we're
> having in Jakarta Batch re: CDI integration
>
> The key question is whether it's OK to continue
only doing CDI bean
> injection into Batch artifacts that are
themselves beans (via the
> CDI-defined standard mechanims: BDA, etc.) ,
rather than injecting
> into any Batch artifact (as the Platform
requires for other specs
> like Servlet, etc.).
>
> An easy starting point to read the argument
laid out is the last message:
> https://www.eclipse.org/lists/jakartabatch-dev/msg00226.html
> plus the two previous embedded in this reply
(from me and from
> Reza), but you maybe don't have to read the
whole thread.
>
> So we're proposing formalizing the current
behavior (which in EE 7
> in Batch 1.0 had been maybe sort of implied but
not mandated as
> Batch was CDI-aware but tried to be DI-neutral
for Spring Batch, etc.).
>
> I do think there's a counter-argument that says
the way integration
> is done in the Jakarta platform is to support
CDI injection into
> "special" artifact instances defined by the
component specs, as
> described in this table:
> https://github.com/eclipse-ee4j/jakartaee-platform/blob/master/
>
specification/src/main/asciidoc/platform/ResourcesNamingInjection.adoc#a651
> and thus Batch should follow this pattern.
>
> In the thread you'll see more pros and cons (I
won't rewrite them
> here for now).
>
> But it does seem to me like the Platform should
have a common
> approach or at least some "institutional
knowledge" to guide each
> spec as it integrates with CDI.
>
> Thank you,
>
------------------------------------------------------
> Scott Kurz
> WebSphere / Open Liberty Batch and Developer
Experience
> skurz@xxxxxxxxxx
>
--------------------------------------------------------
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/
> mailman/listinfo/jakartaee-platform-dev
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/
> mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________