Java EE and WildFly Integration

Initial WildFly integration branch and pull request (not merged):

• https://github.com/chengfang/wildfly/tree/WFLY-508-WFLY-1680
• https://github.com/wildfly/wildfly/pull/4812

Based on feedback and reviews from the initial integration attemp, the following changes and features were added in project JBeret:

• replaced jaxb with stax parsing code and associated object model.
• replaced the use of scanotation with CDI.
• created a set of SPI to abstract out environment-dependent services (e.g., transaction, concurrency, classloader, batch configuration, etc)

Things to fix in the next integration:

• update jberet-core version in wildfly to be the next jberet version that includes the above new features and changes.
• package names have changed, added or removed in JBeret, so need to update jberet package names in wildfly/build/pom.xml.
• remove scanotation dependency from wildfly/pom.xml, wildfly/batch, wildfly/build, wildfly/build/src/main/resources.
• the dependency on transaction implementation libraries (arjuna and narayana-jta) have been moved from jberet-core to jberet-se. So they should be completely removed from wildfly batch integration code.
• transitive dependencies of jberet-core have been declared as optional in project jberet, so no need to exclude them in wildfly/pom.xml.
• implement SPI (jberet-core/src/main/java/org/jberet/spi) for Java EE environment. The Java SE impls are in jberet-se/src/main/java/org/jberet/se and jberet-se/src/main/resources/META-INF/services/org.jberet.spi.BatchEnvironment
• run CTS batch tests (src/com/ibm/jbatch/tck/tests). During first batch integration, we have run majority of these tests and many related issues already been addressed.
• upon undeployment, we may need to remove jobs added by the current application, so any subsequent redeploy can add the same job (may be modified but likely the same job id). Jobs are started and added to job repository at application runtime (not deployment time), so need to remember jobs added by the current application somehow (probably add a method to BatchEnvironment interface).
• need to have a mechanism to pass the batch configuration in subsystem xml snippet to batch container. In previous integration, the batch container runs with default configuration.

Bugs and Issues:

• Umbrella issue for batch integration: https://issues.jboss.org/browse/WFLY-508
• The tracking issue for running CTS batch tests: https://issues.jboss.org/browse/WFLY-1588
• CTS batch tests bugs against Oracle:
  • CTS-114 (Batch API test archives include beans.xml inferring a dependency on CDI not required by the Specification)
  • CTS-115 (Batch TCK test archives include default TCK SPI implementation preventing us to use our own)
  • CTS-116 (JDBC resource reference not declared in Batch test archives which is not portable)