------------------------------------------------------
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 10 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
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev