Uploaded image for project: 'JBeret'
  1. JBeret
  2. JBERET-479

Accept @BatchProperty CDI injection of pojos into batch artifacts

    XMLWordPrintable

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:

      1. 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
      2. 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.

      Attachments

        Activity

          People

            weli@redhat.com Weinan Li
            tamaghei@gmail.com Lorenzo Formenti (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated: