Hi all,
I want to get consensus on filling a TCK challenge against the Batch
TCK. As written in the other thread, I am currently working on getting
a Jakarta Batch 2.1 ready version of Batch EE for usage in TomEE 10
[1]. The most significant change is, that CDI support is now required.
== Details
This implementation passes the Batch TCK with one exception [2]
com.ibm.jbatch.tck.tests.jslxml.CDITests#testCDILookup(...)
This test uses dynamic CDI injections to resolve batch properties in a
non CDI batchlet [3]. As Geronimo BatchEE is a fork of the reference
impl with some neat adjustments, we are more or less using a producer
bean more or less similar to the reference impl: [4, 5]. The major
difference between both impls is, that we are using OWB while the
reference impl uses Weld.
So for the TCK test in question with this line
cdi.select(String.class, new BatchPropertyLiteral("prop1")).get();
in [6], the following will happen:
- OWB will invoke the producer in [4] with a NULL InjectionPoint
- Weld will invoke the producer in [5] with a "fake" InjectionPoint
with InjectionPoint#getMember == NULL.
The JavaDoc of InjectionPoint [7] or more specifically of
InjectionPoint#getMember() does not tell us, if the return value can be
NULL.
However, we find a code example in the interface docs:
@Produces
Logger createLogger(InjectionPoint injectionPoint) {
return
Logger.getLogger(injectionPoint.getMember().getDeclaringClass().getName
());
}
If InjectionPoint#getMember() can be NULL, this code example would
throw a NullPointerException. So from my point of view, Weld violates
the current JavaDoc of InjectionPoint by injecting a "fake"
InjectionPoint without a member.
InjectionPoint#getBean can return NULL and it is stated, any other
method can't - intentionally cause an Instance only defines an
InjectionPoint when there is one.
So from my point of view the test relies on weld-specific behaviour as
there is an ambiquity in the CDI 4.0 spec / javadocs regarding
InjectionPoint#getMember() here. KUDOS to Thomas & Romain for helping &
tracking it down to the actual ambiquity in the Javadocs ;-)
In addition, the Jakarta Batch spec is rather explicit in its
definition in [8]. IMHO, it would be good for the spec to just delegate
the CDI spec and just write something like "As a consequence of the
previous section, an application must be able to get a CDI Bean with a
correct view of a batch property by using CDI" instead of adding
related details which require CDI knowledge.
Before thinking about raising a challenge, I already had a quick
discussion with Thomas and Romain about it and Romain suggested to put
up a PR for an updated test, which does an indirection to a bean, which
is here (+ some discussion / details): [9].
Long story short:
- Did we miss something obvious?
- Does this consistute for a valid challenge against the Batch TCK?
- Any other thoughts on it?
Happy to get some opinions.
Gruß
Richard
[1] https://github.com/apache/geronimo-batchee/pull/21
[2]
https://github.com/eclipse-ee4j/batch-tck/blob/master/com.ibm.jbatch.tck/src/main/java/com/ibm/jbatch/tck/tests/jslxml/CDITests.java#L287
[3]
https://github.com/eclipse-ee4j/batch-tck/blob/master/com.ibm.jbatch.tck/src/main/java/com/ibm/jbatch/tck/artifacts/cdi/NonCDIBeanBatchlet.java
[4]
https://github.com/rzo1/geronimo-batchee/blob/jakarta/jbatch/src/main/java/org/apache/batchee/container/cdi/BatchProducerBean.java#L67
[5]
https://github.com/WASdev/standards.jsr352.jbatch/blob/master/com.ibm.jbatch.container/src/main/java/com/ibm/jbatch/container/cdi/BatchProducerBean.java#L96
[6]
https://github.com/eclipse-ee4j/batch-tck/blob/master/com.ibm.jbatch.tck/src/main/java/com/ibm/jbatch/tck/artifacts/cdi/NonCDIBeanBatchlet.java#L51
[7]
https://jakarta.ee/specifications/cdi/4.0/apidocs/jakarta.cdi/jakarta/enterprise/inject/spi/injectionpoint
[8]
https://jakarta.ee/specifications/batch/2.1/jakarta-batch-spec-2.1#consequences-and-suggested-patterns
[9] https://github.com/eclipse-ee4j/batch-tck/pull/69
