Provide well-defined behavior / ordering / etc. in case where ServiceLoader finds >1 JobOperator impl.

[scottkurz]

In the BatchRuntime.java implementation we now simply return the first JobOperator found (see here).

We could do something like failing fast if we find >1.

Other ideas?

[rmannibucau]

We could also add to JobOperator a default int priority() {return 1000;} and sort them. Implementations must use 1000 but users could wrap any operator and use something higher to force the selection. If multiple higher priority operators are there we fail else we pick it.

A side note is that if the job operator is in a CDI application, we must pick the CDI beans since we enable the operator to be decorated/intercepted so maybe we should also try CDI first - and in CDI a single bean can match so we would be good by design (= if it is ambiguous, user would already have done the job to pick the right one in CDI).

Just throwing ideas, not yet sure which one is good or not. Think I still think the fail fast is the best compromise.

[radcortez]

I believe it would be useful to have a way to control which implementation is selected. Priority seems the best way to do it (and already used in other places across the platform).

[rmannibucau]

(still thinking out loud) but actually all spec which can be selected - ie where it is not contextual as CDI EE, Servlet, JNDI or EJB can be - have a provider method in the lookup entrypoint so it means it is more about adding BatchRuntime.getJoboperator(String provider) than anything else probably (using as ref bval, cdi se, jsonb, jsonp, jpa but others have alternate mecanism like JAXRS, JSF, ...).

note that the standard lookup strategy is also to

0. if explicit in parameters use it
1. check a spec system property
2. (optional) check a lib/<file>.properties
3. use service discovery (loader these days)

[scottkurz]

Just want to reiterate that this is NOT currently planned for 2.1. (See the 2.1 / EE 10 milestone: https://github.com/eclipse-ee4j/batch-api/milestone/1)