JSR-170 and Spring

There are quite a couple of solutions to your problem:
1. you can see if Magnolia doesn't already support such a feature and ask for it. I know Magnolia team is very responsive.
2. if the content is loaded inside the jackrabbit repository you can simply configure (using spring support for jsr-170 for example) your code to look at the repository and access it or export it through the JCR api.
3. use some JCR tools - there are some out there - to see your repository and extract the info from it.
Remember that one of the greatest strength of JSR-170 is that using the standardized API you can access the repository from web, command line applicatin or even a non-java environment.

When i study the springmodules jcr project and souce,i dont found how to config it to support multiple workspace?
Any suggestion?
Thx!

If you only have one workspace (or some fixed number of them) in your app, you can use dependency injection to manage them all (in your applicationContext.xml files, you'd create a JcrSessionFactory for each repsoitory/workspace/credentials combination, and create a corresponding JcrDaoSupport subclass for each of those JcrSessionFactory beans.

In my case, I've got a workspace for each user and that means I can't create them until the application is running and I have user accounts created. The system I'm working on solves the problem of how you do SpringModules JCR based access to workspaces created dynamically, while the application is running. I'm still working on my solution to this problem. When I confirm that it works for my app, I'm going to write a generalized example and some documentation, as I have time.

The way I've got it set up, there's two hierarchies: a repository-based hierarchy and a workspace-based hierarchy. The repository-based hierarchy is intended to be the "visible" outer layer of the system; this is where I implement an interface that is used by other parts of my application. The workspace-based hierarchy is used to actually perform the work of accessing Nodes in the repository's workspaces and is only used by the repository-based class hierarchy. Here's more detailed descriptions:

Class: AbstractJcrDao
Extends: Object
Implements: <none>
Description:
This class has several properties that will be used by subclasses: systemRepository, systemCredentials, requireTransactionalSession. All three can be set by dependency injection. In my app, I have only one user/pass, so this is a good place for me to keep the Credentials; if you have multiple users for your repository, you may want to put the credentials elsewhere. There are setters and getters for each of the properties. There is also a protected createWorkspace( String name ) method that subclasses can use to create their needed workspaces.

The createWorkspace( String name ) method works by first creating a JcrSessionFactory with the repository, default workspace, and system credentials. It calls jcrTemplate.setAllowCreate( !requireTransactionalSession ) to enforce the the transactional requirement (which I need in my app). I then call jcrTemplate.execute( new JcrCallback() {...}, true ); and in the callback create the new workspace. Since creating a workspace is implementation dependent, I may move this to a utility interface that can be implemented for each JCR package I work with, but right now I'm only using Jackrabbit so this isn't a priority for me. Actually, Costin, if you read this, that would be a useful hierarchy to have someplace in the SpringModule's JCR package, possibly an addition to JcrUtils()?

Class: JcrWorkspaceDao
Extends: JcrDaoSupport
Implements: <none>
Description:
This is my other abstract class. While AbstractJcrDao and its hierarchy is concerned with access to the entire repository, this hierarchy focuses on a single Workspace; most of the actual work takes place in this hierarchy. Currently it provides two functions: checkWorkspace() and logNodeTree( Node n ). The former method simply tries to create a new session by calling getJcrTemplate().execute( new JcrCallback() { ... }, true ); and simply logging the fact that the instance has been created for the particular workspace. The latter method simply walks a a Node hierarchy and logs the names of the nodes in the hierarchy; this is a useful tool for ensuring the workspace contains the node tree you think it does.


Class: Jcr<DataType>Dao
Extends: AbstractJcrDao
Implements: <DataType>Dao
Description:
In my system, I've got one workspace per user, with several types of data stored in each workspace; therefore, I have one class of this sort for each of those data types. The interface that it implements defines the action methods that can be called, much as you would expect for a database DAO; in fact, you should be able to replace the Jcr-based DAO with a JDBC-based DAO and the rest of your code won't notice because only your Spring dependency injection file had to change. This class implements those action methods (addSomething( ... ), findSomething( ... ), deleteSomething( ... ), etc.). Each of these action methods is delegated to a subclass of JcrWorkspaceDao which is created by the Jcr<DataType>WorkspaceDao getWorkspaceDao( String name ) method in this class.

Jcr<DataType>WorkspaceDao getWorkspaceDao( String name ) works by creating a JcrSessionFactory with the repository and credentials from the abstract superclass, and the workspace name given to it by the action method. I then create a JcrTemplate with the session factory, and call jcrTemplate.setAllowCreate( !isTransactionRequired() ) to ensure that I get transactional sessions when I need them (at runtime and in Integration testing, but not during Unit testing). With the JcrTemplate, I create a new Jcr<DataType>WorkspaceDao instance (the JcrTemplate is passed to the constructor). If the workspace specified by the session doesn't exist, the constructor throws a DataAccessResourceFailureException (from the org.springframework.dao package). I check the cause of the exception to ensure it really is a NoSuchWorkspaceException (from the javax.jcr package). If it is, I call the superclass createWorkspace() method for the workspace name. Assuming that succeeds, I try creating the new Jcr<DataType>WorkspaceDao instance again (this time I don't try to catch any exceptions). I then call the workspaceDao.initialize() method to create required or default Nodes in the new workspace.

Class: Jcr<DataType>WorkspaceDao
Extends: JcrWorkspaceDao
Implements: <none>
Description:

This is where the real work of this contraption is done. All the major interactions with the JCR Session objects take place here. The only constructor requires a JcrTemplate, which is passed to the superclass's setJcrTemplate() method (in JcrDaoSupport) before calling the superclass afterPropertiesSet() method (also in JcrDaoSupport). The purpose with these first two calls is to simulate the dependency injection workflow. I then call the checkWorkspace() method in the immediate superclass, JcrWorkspaceDao, to ensure the workspace has been created. If the workspace doesn't exist, the JcrSessionFactory will fail to create a session and throw an exception which is allowed to fall back to the caller to be processed as described above.

There's also an initialize() method to do initial setup in a newly created workspace for this type of data. All the other methods are action methods that actually add, delete, search, and edit Nodes in the workspace.

---

So far, things are looking good. Workspaces get created on the fly as they are needed, and they are initialized. I'm having trouble with actually creating Nodes and setting properties in my action methods, but this seems to be an issue I'm having with Jackrabbit, not SpringModule's JCR package. Hopefully I'll get it worked out in the next day or two and be able to confirm that this setup actually does what its intended to do.

Nice answer!

Quote:

---

Since creating a workspace is implementation dependent, I may move this to a utility interface that can be implemented for each JCR package I work with, but right now I'm only using Jackrabbit so this isn't a priority for me. Actually, Costin, if you read this, that would be a useful hierarchy to have someplace in the SpringModule's JCR package, possibly an addition to JcrUtils()?

---

I'm not sure I'm following you - creating a workspace is standardized - from the javadocs:

Quote:

---

the Workspace object can be acquired by calling Session.getWorkspace() on the associated Session object.

---

.
Please post some code so I can get an idea about what you are need.

Hi Costin,

Getting the workspace from the session is standardized. However, making a new workspace is not. From the Jackrabbit FAQ:

Quote:

---

How do I create new workspaces in Jackrabbit?
The JCR API does not contain features for creating or managing workspaces, so you need to use Jackrabbit-specific functionality for creating new workspaces.

You can create a new workspace either manually or programmatically. The manual way is to create a new workspace directory within the repository home directory and to place a new workspace.xml configuration file in that folder. You can use the configuration file of an existing workspace as an example, just remember to change the name of the workspace in the <Workspace name="...">" tag. See the Configuring Jackrabbit page for configuration details. Note also that you need to restart the repository instance to access the new workspace.

The programmatic way is to acquire a Workspace instance using the normal JCR API and to cast the instance to the Jackrabbit WorkspaceImpl class. You can then use the WorkspaceImpl.createWorkspace(String) method to create new workspaces.

---

Perhaps there are some implementations that automatically create a workspace when it doesn't exist, but since I've only dealt with Jackrabbit, I'm not aware of them.

I'll have to see how other implementations (jeceira for example) create their workspaces; in most of the cases a fixed number of workspaces will be used, usually through configuration (which can be programaticallly or declaratively) so there wouldn't be much gain from having such a method.
Moreover, it would need separate class for every JCR-implementation which complicates things.

Well, there's already separate classes for jackrabbit and jeceira... they both have a RepositoryFactoryBean, and when jeceira is able to handle transactions, I'm assuming it will get a LocalTransactionManager as well. The code I'm suggesting would be very simple, and could be added to JcrUtils.java

Code:

---

public void createWorkspace( String name )
{
    throw new InvalidDataAccessApiUsageException(
        "JCR does not specify a mechanism for creating workspaces. You must "
        + "use an implementation specific subclass." );
}

---

This way, if the implementation doesn't support workspace creation in a manner that is accessible at runtime, this method will do the right thing. Concrete subclasses that have implementation-specific utilities can also do the right thing and create the workspace. In the case of Jackrabbit, for that to work, the implementation specific subclass would need to have a JcrSessionFactory (set to the default workspace) wired into it.

I do agree though, that it may be more work than is needed to make things work for the common case.

Mark,thank you very much!
Great idea!
Can you post some code?
Thx!

All the code I have is for my system, and I'm not even positive it works yet. Like I said, when am sure that this scheme works, I'll put together a small example to demonstrate it; code will be included in that. But that's a few weeks off a this point. I'm under a hard deadline for the end of March so I can't spare the cycles for the example until after that deadline is passed.

Mark

Mark,
I implement it by your method,and some method raise exception:

javax.jcr.RepositoryException: this session has been closed
at org.apache.jackrabbit.core.SessionImpl.sanityCheck (SessionImpl.java:339)

How do you solved the problem?