When deploying ModeShape inside JBoss AS7, we have several modules:

• javax.jcr - contains the standard JCR API and has no dependencies
• org.modeshape.jcr.api - contains the ModeShape extensions to the JCR API and depends only on javax.jcr
• org.modeshape - is the ModeShape subsystem and the engine, and contains most of the ModeShape JARs (e.g., modeshape-jcr, modeshape-common, modeshape-schematic, etc.)
• org.modeshape.jdbc - contains the JDBC driver that sits on top of the JCR API; depends on org.modeshape.
• org.modeshape.sequencer.* - one each for each our sequencers; each contains its JAR plus any dependencies

The plan was to only expose javax.jcr and org.modeshape.jcr.api to WAR and EAR files (or any other deployable unit), which means that our javax.jcr.RepositoryFactory implementation (which is in the modeshape-jcr JAR in the org.modeshape module) is not visible.

Since all of the Repository instances are registered in JNDI, we should just have a JNDI-based RepositoryFactory implementation in the org.modeshape.jcr.api module. That RepositoryFactory would actually work for any javax.jcr.Repository instance registered in JNDI.

The existing JNDI-based logic inside our existing JcrRepositoryFactory class could then be removed, as it no longer has to do anything with JNDI lookups. The ServiceLoader mechanism can work with any number of RepositoryFactory implementations.