Fixes are available
9.0.0.6: WebSphere Application Server traditional V9.0 Fix Pack 6
9.0.0.7: WebSphere Application Server traditional V9.0 Fix Pack 7
9.0.0.8: WebSphere Application Server traditional V9.0 Fix Pack 8
9.0.0.9: WebSphere Application Server traditional V9.0 Fix Pack 9
9.0.0.10: WebSphere Application Server traditional V9.0 Fix Pack 10
9.0.0.11: WebSphere Application Server traditional V9.0 Fix Pack 11
9.0.5.0: WebSphere Application Server traditional Version 9.0.5 Refresh Pack
9.0.5.1: WebSphere Application Server traditional Version 9.0.5 Fix Pack 1
9.0.5.2: WebSphere Application Server traditional Version 9.0.5 Fix Pack 2
9.0.5.3: WebSphere Application Server traditional Version 9.0.5 Fix Pack 3
9.0.5.4: WebSphere Application Server traditional Version 9.0.5 Fix Pack 4
9.0.5.5: WebSphere Application Server traditional Version 9.0.5 Fix Pack 5
WebSphere Application Server traditional 9.0.5.6
9.0.5.7: WebSphere Application Server traditional Version 9.0.5 Fix Pack 7
9.0.5.8: WebSphere Application Server traditional Version 9.0.5.8
9.0.5.9: WebSphere Application Server traditional Version 9.0.5.9
9.0.5.10: WebSphere Application Server traditional Version 9.0.5.10
9.0.5.11: WebSphere Application Server traditional Version 9.0.5.11
APAR status
Closed as program error.
Error description
When using a third-party JBatch implementation, such as Apache BatchEE, the internal IBM Batch implementation can still provide several CDI producers for various JBatch artifacts. This can result in an AmbiguousResolutionException. Is there a way to disable the internal IBM Batch implementation to prevent this problem from occurring?
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: Users of the Java Batch 1.0 (JSR 352) * * function in IBM WebSphere Application * * Server. * **************************************************************** * PROBLEM DESCRIPTION: There is no way to use a third * * party JSR 352 implementation in the * * application server, yet * * WebSphere Application Server * * traditional provides only a limited * * JSR 352 implementation. * **************************************************************** * RECOMMENDATION: * **************************************************************** In WebSphere Application Server traditional, only a limited JSR 352 implementation is provided. The Job Repository implementation is in-memory (there is no persistent job execution data) and the operational features provided in Liberty (via the batchManagement-1.0 feature) are not present. Furthermore, JSR-352 batch applications cannot be managed in the Compute Grid job scheduler. If a user attempts to use a third party JSR 352 implementation, however, it may collide with the WebSphere Application Server JSR 352 implementation. In particular, if the third party implementation uses a CDI Extension in a similar manner as the WebSphere Application Server implementation, you may see an error like this on application start, preventing the application from starting successfully. org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type String with qualifiers @BatchProperty at injection point [BackedAnnotatedField] @Inject @BatchProperty private mypkg.MyItemReader.param1 at mypkg.MyItemReader.param1(MyItemReader.java:0) Possible dependencies: - Producer Method [String] with qualifiers [@BatchProperty @Any] declared as [[UnbackedAnnotatedMethod] @Produces @BatchProperty public org.apache.batchee.container.cdi.BatchProducerBean.produceProper ty(InjectionPoint)], - Producer Method [String] with qualifiers [@BatchProperty @Any] declared as [[UnbackedAnnotatedMethod] @Produces @BatchProperty @Dependent public com.ibm.ws.jbatch.cdi.BatchProducerBean.produceProperty(Injectio nPoint)] at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDepl oymentProblems(Validator.java:363) at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Valida tor.java:277) at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator .java:130) at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java :151) at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:4 94) at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(Concurrent Validator.java:64) at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(Concurrent Validator.java:62) at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(Iterat iveWorkerTaskFactory.java:62) at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(Iterat iveWorkerTaskFactory.java:55) at java.util.concurrent.FutureTask.run(FutureTask.java:277) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExec utor.java:1153) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExe cutor.java:628) at java.lang.Thread.run(Thread.java:785) at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(Deplo yedApplicationImpl.java:1187) at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication (ApplicationMgrImpl.java:799) If the application does start, one could also get the Websphere Application Server JobOperator implementation (unintentionally) via the BatchRuntime.getJobOperator() factory API, instead of the (intended) third party implementation of JobOperator.
Problem conclusion
A new JVM system property, "com.ibm.ws.jbatch.disable" was introduced. When set to "true" (the default is "false"), then: a) when the BatchRuntime.getJobOperator() method is called (on class javax.batch.runtime.BatchRuntime), it will not return the WebSphere Application Server JobOperator implementation. b) the WebSphere Application Server batch CDI Extension will not perform field injection of batch properties and contexts (that is, fields marked with @Inject @BatchProperty String and @Inject JobContext, @Inject StepContext). ---------------------------- The fix for this APAR is currently targeted for inclusion in fix pack 9.0.0.6. Please refer to the Recommended Updates page for delivery information: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
Temporary fix
Comments
APAR Information
APAR number
PI81777
Reported component name
WEBS APP SERV N
Reported component ID
5724H8800
Reported release
900
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2017-05-17
Closed date
2017-10-03
Last modified date
2017-11-03
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
WEBS APP SERV N
Fixed component ID
5724H8800
Applicable component levels
R900 PSY
UP
Document Information
Modified date:
04 May 2022