Details
-
Feature Request
-
Resolution: Unresolved
-
Trivial
-
None
-
None
-
None
-
None
Description
Hi,
I'm currently into development of a couple of batch artifacts. To perform unit tests on them without running a whole job with Maven's failsafe plugin I'm using the weld-junit5 dependency, and tests are going more or less along this line:
@Named @Dependent public class MyPartitionMapper implements PartitionMapper { @Inject @BatchProperty private File resource; ... }
@ExtendWith(WeldJunit5AutoExtension.class) @AddBeanClasses(MyPartitionMapper.class) @EnableAlternatives(MyPartitionMapperTest.class) public class MyPartitionMapperTest { @Produces @BatchProperty @Alternative private File resource() { return resource; } @Test public void testCDIInjection(PartitionMapper mapper) { assertNotNull(mapper); } ... }
Alternatively to this approach, I can also avoid to add any producer in my test class, switch the @EnableAlternatives annotation and add @AddExtensions(BatchCDIExtension.class) to have an approach similar to what I may have to the actual JBeret set-up.
The real issue with CDI is when I have multiple @BatchProperty-annotated parameters in my artifact that share the same type, this opens one to one of two scenarios:
- if only one producer is left on the test class: the producer field in the test class produces the same value for both of the fields
- if multiple producers for the same type are being put on the test class: it's required to add the additional @Named annotation for both the fields in the batch artifact and in the test class and everything works for the unit test, but this breaks the artifact when deployed outside of the unit test due to the missing @Named dependency.
My proposal is then to support Pojo's injection, instead of simple flat types into the batch artifact. This will probably mean to enhance the spec to support multiple <properties /> tags into a batch artifact xml, something resemblant of a Spring configuration xml file.
Do you think it makes sense? My personal opinion is that this kind of approach may also improve reusability of some recurring groups of parameters.
Thank you, regards.