Commits : Individual Commit
Analyzed 6 days
ago based on code collected 6 days ago.
Commit ID 691fc2338b0147de2ac6c8eb41f03ed44d0204d2
|
Contributor: | Randall Hauch | Files Modified: | 625 |
| Date: | 08-June-2012 at 12:38 | Lines Added: | 34403 | |
| Repository: | git://github.com/ModeShape/modeshape.git master | Lines Removed: | 33791 | |
| Commit Comment: | MODE-1500 MODE-1501 Corrected AS7 integration (JNDI names and assemblies) Several issues were identified and corrected. The first was that although the ModeShape engine (e.g, the 'org.modeshape.jcr.api.Repositories' implementation) was registered in JNDI, the Repository instances were not correctly being registered and were thus not able to be found by deployed components. This was rectified, and now the engine and each repository is properly registered in JNDI. Secondly, the JNDI names where the engine and repositories are registered were changed to more closely align with the naming patterns used by other implementations. The engine is always registered at "jcr" in the "java:" namespace (i.e, "java:/jcr"), while each repository is registered at "jcr/{repositoryName}" in the "java:" namespace. For example, the repository named "sample" could be found in JNDI at "java:/jcr/sample" or "jcr/sample". This conforms to the many examples that configure a JCR repository at "jcr/local" (where only one repository is used). Note that the new default JNDI names are different than ModeShape 2.x, which used "jcr/local" as the location of the engine and "jcr/local/{repositoryName}" as the default location for each repository. However, should the old style still be needed for a repository, the repository can be configured with a custom JNDI name. Thirdly, when a repository is configured to have a custom JNDI name, the repository is registered under the specified name (as before), but now the repository is still registered under the 'jcr/{repositoryName}' name. This means that code can find the repository under either name. Fourthly, the assembly for the ModeShape kit was moved from the 'deploy/jbossas' Maven module (which installed the resulting ZIP into the Maven repository at 'org/modeshape/jbossas/jbossas-{version}-jbossas-7-dist.zip') and into the "modeshape-distribution" module, which is where the binary and source distributions are assembled. And the assembly descriptor was moved to the "modeshape-assembly-descriptors" module (again, where the other assembly descriptors are managed and installed into the Maven repository). Fifthly, new integration tests were written to verify that EJBs (of various flavors) can find the ModeShape repositories correctly using the 4 different ways of looking up a repository: 1) looking up a repository in JNDI 2) looking up the Repositories interface and using it to get a named repository 3) using RepositoryFactory with a single URL (e.g., "jndi:jcr/sample" or "jndi:jcr?repositoryName=sample") 4) using RepositoryFactory with a URL to the engine (e.g, "jndi:jcr") and the name of the repository These new integration tests are in a new Maven module that downloads AS7 and the ModeShape kit from the Maven repository and unpacks them into the 'target' directory. When Surefire runs, this managed server is started, the Arquillian tests are run, and then the server is shutdown. Each Arquillian test involves creating a WAR file that will be deployed by Arquillian to the running server, running the unit tests, and then undeploying the WAR file. The tests can also be run with a different profile so that the tests are deployed and executed in a separate server installation (as specified by the $JBOSS_HOME variable). Finally, the older "modeshape-integration-tests" module and the new "modeshape-jbossas-integration-tests" were relocated to a new top-level folder called 'integration' in the source code. Like the other top-level directories in our codebase, this is also a Maven module that can be used to run all of the integration tests. And the '-Pintegration' profile was brought back so that the distributions are not created and the integration tests not run during the normal builds. Thus, to run a normal developer build (with all the unit tests but none of the integration tests) simply use mvn clean install while the following command will build everything, run all the unit tests, build the AS7 assembly, and run the integration tests: mvn clean install -Pintegration As before, running an 'assembly' build (used for releases) will build everything, run all the unit tests, build the AS7, binary, and source assemblies (including JavaDoc), run the integration tests, and run the demos: mvn clean install -Passembly |
|||
Changes by Language
| Language | Code Added | Code Removed | Comments Added | Comment Removed | Blanks Added | Blanks Removed | |
|---|---|---|---|---|---|---|---|
| XML | 16503 | 16341 | 3061 | 3048 | 226 | 235 | |
| Java | 7631 | 7382 | 2387 | 2344 | 1455 | 1413 | |
| XML Schema | 2065 | 2065 | 311 | 311 | 145 | 145 | |
| MetaFont | 75 | 0 | 0 | 0 | 37 | 0 | |
| shell script | 68 | 68 | 392 | 392 | 47 | 47 | |
Changes by File
Showing page 1 of 63
| File | Language | Code Added | Code Removed | Comments Added | Comment Removed | Blanks Added | Blanks Removed | |
|---|---|---|---|---|---|---|---|---|
| deploy/jbossas/assembly/kit-as7.xml | XML | 0 | 205 | 0 | 21 | 0 | 34 | |
| deploy/jbossas/build.xml | XML | 0 | 37 | 0 | 36 | 0 | 7 | |
| .../deployments/modeshape-rest.war.dodeploy | No source code was detected in this file. | |||||||
| ...ape/jboss/service/RepositoryService.java | Java | 5 | 1 | 0 | 0 | 0 | 0 | |
| ...oss/subsystem/AddModeShapeSubsystem.java | Java | 2 | 0 | 0 | 0 | 1 | 0 | |
| ...shape/jboss/subsystem/AddRepository.java | Java | 30 | 12 | 0 | 16 | 1 | 0 | |
| .../jboss/subsystem/ModeShapeJndiNames.java | Java | 2 | 10 | 0 | 2 | 0 | 0 | |
| ...rest-war/src/main/webapp/WEB-INF/web.xml | XML | 1 | 1 | 0 | 0 | 0 | 0 | |
| deploy/jbossas/pom.xml | XML | 1 | 56 | 1 | 4 | 0 | 2 | |
| ...tion/modeshape-integration-tests/pom.xml | XML | 347 | 0 | 62 | 0 | 11 | 0 | |
Copyright
©
2013
Black Duck Software, Inc.
and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a
Creative Commons Attribution 3.0 Unported License
. Ohloh
®
and the Ohloh logo are trademarks of
Black Duck Software, Inc.
in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.