Add tests to validate more dynamic (advanced) CDI integration use cases

[scottkurz]

The idea here is to follow up on the topics raised in the discussion of #69 (which we might informally describe as a "pending" TCK challenge, since a formal challenge hasn't been raised at the time of this writing).

It looks though that the CDITests#testCDILookup is on its way to getting excluded from the current TCK.
A related follow-up discussion is happening in this CDI issue .

From the Batch TCK perspective, what could we add in its place?

Some ideas:

1. The idea in the PR of @rzo1 to add a new test app bean to hold the batch property injections, and then validate the non-bean batch artifact can access this via cdi.select(), the line NamedTestBean bean = cdi.select(NamedTestBean.class).get();
2. Romain's idea described in comment to get a BeanManager instance via cdi.select() from a non-bean, then do

 final var creationalContext = beanManager.createCreationalContext(null);
    try {
        return (String) beanManager.getInjectableReference(new InjectionPoint() {
            private final Set<Annotation> qualifiers = Set.of(
                    new BatchPropertyLiteral(key),
      ...

3. Another idea @Azquelt suggested to me in conversation was to inject an Instance<Object> , this time into a bean, and to try to do something like this:

@Inject Instance<Object> instance;
 // then later
instance.select(String.class, new BatchPropertyLiteral("myProperty")).get();

The thought was that this too might expose similar gaps or ambiguities, some of which will be discussed in the CDI follow-up issue above.

4. I suppose it's possible that CDI decides the Jakarta Batch test should've worked as it originally was, and OWB ends up supporting it, and we reinstate the test to look like it does currently, like it did in the 2.1 TCK.

THOUGHTS

I would say we are at liberty to add zero tests, one test, or N tests.. it is up to our judgement what to do or not do here.