Note the "drop3" part of the name alludes to the earlier drop1 and drop2 over the past several months.
This numbering will no longer be updated, i.e. "drop3" is the final drop, which will be refreshed as needed until JSR approval.
The refreshes will be identified by an internal build version id, which will have Maven and Git correspondences as well, listed below.
NOTE: You must recreate database tables since the DDLs have changed
(at the moment we're not especially in synch with 1.4, 1.5, or 1.6.. it's item by item, bug by bug where we're at)
I deleted the earlier SE TCK README (.odt) document. The new README is a PDF in
the TCK zip at path: doc/jsr352-tck-reference-guide
- HTTP browse
- Git Checkout URL: git://java.net/jbatch~jsr-352-git-repository
- Recommended Git version: 459973afa736613630666e76e1f40bdec9f23e01
- 137 test methods
- 6 ignored/disabled
- 3 failures (testJobAttributeRestartableFalse, testMultiPartRestart, testOneArtifactIsJobAndStepListener)
- 128 pass
For a given drop, the intent is to allow tracking of:
- misalignment vs. spec (in area XXX we are using the API in manner YYY like the 1.2 spec, though the 1.4 spec says ZZZZ)
- intended function and/or coverage (we still are planning on adding test/RI function for XXX)
- bugs (we meant to do XXX but it just isn't working as we thought)
0313a (I didn't give this that much thought except to check off previously listed TODOs and misalignments
- RI - In SE, I believe we don't correctly load JSL from META-INF/batch-jobs in an archive, but require expansion on disk
- test with IBM, Oracle JREs
- RI,TCK - JobOperator has extra method getExecutions(JobInstance instance)
- RI - JobOperator could use public modifier (minor, style points)
- RI,TCK - JobOperator uses getParameters(JobInstance instance) spec uses getParameters(long executionId)
- RI,TCK - JobOperator abandon, RI/TCK uses abandon(JobExecution jobExecution) while spec uses abandon(long executionId)
- RI - JobOperator restart already added, but parm names, Javadoc not aligned with spec
- Ri,TCK - StepExecution - Spec has long getId() and RI/TCK is making use of String getName().
- RI/TCK also has String getStepId() (not used) and long getJobExecutionId() (used for logging but not essential).
- We need to revist this and if we think we need more from the spec, raise the issue.
- RI/TCK - support multiple include/excludes on skip/retry... in spite of the XSD support, the RI will throw an exception if it sees more than one of each of include/exclude
- RI - JobOperator.getStepExecutions return type not fully parameterized as in spec with '?' (minor)
- RI, TCK - JobExecution has methods: long getExecutionId() , long getInstanceId() while spec has neither but has method long getId()
- Spec - JobInstance - spec has: long getId() in addition to long getInstanceId(), so getId() can probably just be removed
- TCK - In DeciderTestsDecider, stil relying on injected StepContext from older spec version
- RI,TCK - JobOperator abandon, RI/TCK uses abandon(JobInstance instance) while spec uses abandon(long executionId)
- RI,TCK - Uses CheckpointAlgorithm.checkpointTimeout(int timeout) spec uses CheckpointAlgorithm.checkpointTimeout()
- TCK - Remove some unused XMLs
- support other DBs besides Derby (ship DDLs)
- Ship javax.inject impl within TCK, RI
- Java package rename (to com.ibm.jbatch.* ) and XSD targetNamespace rename (to http://xmlns.jcp.org/xml/ns/javaee)
- Note the Glassfish configuration code calling JBatch will need to be tweaked.
- Note all JSLs will need to be adjusted for the TNS change.
- RI - Checkpoint timeout tests (EE-only)
- RI - testPartitionedCollectorAnalyzerReducerChunkRestartItemCount10 - deadlock in Glassfish
- partitioned batchlet String return value as exit status support
- Repackaged and refactored SPIs, e.g. to be used in Glassfish
- Addressed some TCK criticisms in Bug 4702
- Added JobOperator.getRunningExecutions()
- Adjust StepContext/StepExecution persistent user data to reflect switch from Externalizable to Serializable (coming in PFD 1.5), but didn't do reader/writer checkpoint yet.
- RI, TCK - Scan for unused source that was left in unnecessarily
- RI, TCK - Javadoc
- TCK - Produce TCK coverage statement
- TCK - Along with collecting data to produce our coverage statement we expect to find a handful of API methods that are still unexercised, and we wish to close these gaps.
- RI - Document security permissions (Java 2 security) needed
- RI - more of the finer details of restart - rerunning of deciders, limits, etc.