ModeShape as a EAP6.1 Subsystem but programmatically repository creation is required

[nilian]

Hi,

we are currently evaluating ModeShape for a customer and would like to do the following:

- Using ModeShape as a subsystem in EAP6.1 ... feeling more naturally than embedding it in the application

- Having the ability to create new repositories programmatically (e.g. when a new user is newly registrated in the system, a new repository should be created)

So far it seems thats not possible. Did I overlook something, or is embedding modeshape and using the modeshape API to programmatically deploy new repositories the way to go ?

How well performs an embedded ModeShape regarding transactionhandling and clustering ... it seems this should work right out of the box with the subsystem approach.

Best regards,

Daniel

[rhauch]

we are currently evaluating ModeShape for a customer and would like to do the following:

- Using ModeShape as a subsystem in EAP6.1 ... feeling more naturally than embedding it in the application

- Having the ability to create new repositories programmatically (e.g. when a new user is newly registrated in the system, a new repository should be created)

So far it seems thats not possible. Did I overlook something...?

ModeShape's subsystem for EAP 6.1 is intended primarily to allow administrators to manage and configure repositories using the EAP management tools, like the web-based console and command line interface (CLI). As a subsystem, it does fit very nicely into the EAP system, keeping all aspects of repository management and lifecycle out of the purview of your applications. The repositories are just there, so all applications have to do is simply look them up. (And yes, they are started on-demand, ensuring that resources are kept to a minimum until they are needed.)

Now, EAP's console and CLI are actually built on top of a management API, and it comes with an HTTP API endpoint and a native API endpoint. I can't find anything about the DMR in the the EAP documentation, but the AS7.1 documentation is here. With it, you should be able to do all of the same things that you can do with ModeShape and Infinispan via the CLI. Note that some configuration changes do take effect only after restarting the subsystem, though the impact upon clients will vary based upon what is changed. A number of operations (e.g., adding and removing repositories are some obvious ones) will not require restarting the subsystem. (Making certain configuration changes in the the embedded case will also require restarting the repository.)

... or is embedding modeshape and using the modeshape API to programmatically deploy new repositories the way to go ?

How well performs an embedded ModeShape regarding transactionhandling and clustering ... it seems this should work right out of the box with the subsystem approach.

It is certainly possible to embed a ModeShape engine within your application on EAP6.1. You'll have to make sure that your application has access to the proper ModeShape modules (see here, though you'll likely have to add at a minimum the "org.modeshape" module, too). To my knowledge we haven't tested this, nor whether the engine will correctly register the repository into JNDI this way. (It should, as long as code running in your application has privilege to do that.) But you can give it a whirl.

As far as performance, I don't think there will really be much of a difference between embedding it in your application or using the EAP subsystem. Really, the EAP subsystem is just running a ModeShape engine instance, and the repositories and subsystem are integrated into EAP to get all the benefits of EAP: repositories in the EAP subsystem can be monitored via RHQ and managed with the CLI or other tools (including EAP's fantastic domain management for high availability configurations). If you embed the repository, you'll get none of this and will have to provide all of that functionality.