[sverker]

For 2.x I think it makes sense to keep the same configuration as is used in the as5/as6 deployments and from client perspecive it should be no changes to connect to it.

For 3.x I believe it makes sense to update the architecture so that it can plug in  and be managed as the other subsystems. In the current code there is a RepositoryService, which doesn't do anything yet. Comparing with the modeshape-config.xml file there are entries for repositories, sources, sequencers and clustering. May be that each of these should have their own service, or all be under an EngineService. Both approaches should be fairly straight forward (once the subsystem-specific parts can be figured out). I don't know how much is changed in the architecture from 2.x to 3.x though.

[tejones]

Cool... sounds like we are on the same page. So, keep on the current path for 2.x and we can try to work through your issues.

I think we should only need the EngineService for 3.x to start and maintain a refererence the JcrEngine. Then we can use that instance to execute other operations get metrics via a ModeShapeOperationHandler.

[rhauch]

For 3.x I believe it makes sense to update the architecture so that it can plug in  and be managed as the other subsystems. In the current code there is a RepositoryService, which doesn't do anything yet. Comparing with the modeshape-config.xml file there are entries for repositories, sources, sequencers and clustering. May be that each of these should have their own service, or all be under an EngineService. Both approaches should be fairly straight forward (once the subsystem-specific parts can be figured out). I don't know how much is changed in the architecture from 2.x to 3.x though.

In 3.x, the JcrEngine (in 'modeshape-jcr-redux' that will soon be renamed to 'modeshape-jcr') contains 0+ JcrRepository instances, which can be dynamically added, removed, started, stopped and even configured independently. In fact, most (but not all) of the configuration options can be changed while the JcrRepository is running and being used. The question is how best to integrate this into AS7.

We're still learning how to best to do this integration, and after talking about it with Ramesh (co-lead of the Teiid project), we probably want to consider making each repository a service. Doing so would mean we get lifecycle events for our service, including notification when dependent services (e.g., Infinispan) become no longer available. Plus, I think we'll get better JNDI integration, so when a client looks up a repository via JNDI (or via the AS7 service mechanism) and the repository is not running, AS7 will start the repository. Are there other advantages? Is the only disadvantage the extra work involved?

This is obviously different than what Ted suggested, but last week I think I talked Ted out of having a service for each repository. I think this discussion shows that was premature and possibly incorrect on my part. So while we might start out (in the alphas and early betas) not having a service for each repository, we should definitely talk about it. Apologies, Ted.

[rhauch]

Comparing with the modeshape-config.xml file there are entries for repositories, sources, sequencers and clustering.

I neglected to comment about sources, sequencers and clustering. In 2.x, each of these were managed at the engine level, and so they were treated as being independent of repositories. As I mentioned above, in 3.x each repository will be entirely independent of all other repositories, and this extends to sequencers, clustering, other components (like MIME type detectors, text extractors, security providers, etc.). Thus, because their lifecycle mirrors that of the repository and because the repository will be an AS7 service, the sequencers, clustering, and other components IMO don't need to be represented by AS7 services.

[sverker]

I think it makes sense to have one service per repository, and shouldn't be so much extra work to implement.