Hi all!

Looks nice and simple. A colleague of mine at Mindquarry did a jcr- persistence framework that is very, very similar to JPA. I can't remember why he did not use it directly, so he recreated the basic annotation classes like Entity, ID or NamedQuery. Probably because you need some special jcr-compatible extensions.

Here is an example [4] which would map to /users/*. Note the parentFolder setting of @Entity and also that querying is just like in JPA, but using XPath instead:

@SerializationName("user") @Entity(parentFolder=User.PARENT_FOLDER) @NamedQueries({ @NamedQuery(name="userByLogin", query="/users/{$userId}"), @NamedQuery(name="allUsers", query="/users/*[local-name() != 'photos']"), @NamedQuery(name="getUsersForTeam", query="/users/*[jcr:content/ user/teams/item/@reference = /teamspaces/{$teamId}/@jcr:uuid]") }) public class User {

public static final String PARENT_FOLDER = "users";

@Id private String login = ""; private String pwd = "";

public String firstname = ""; public String lastname = "";

private List<String> skills; private String[] skillsArray;

private List<Team> teams;

public Group group;

..... }

Example of creating/querying objects:

Team team = makeTestTeam(); // new Team() + setting values currentSession().persist(team);

List<Team> teams = new LinkedList<Team>(); teams.add(team); User user = makeTestUser(); // new User() + setting values user.setTeams(teams);

currentSession().persist(user);

Session session = sessionFactory_.currentSession(); List queryResult = session.query("getUsersForTeam", TEST_TEAM_ID);

assertEquals(1, queryResult.size());

See the framework [1], API classes (eg. Entity) at [2], and the test code for more samples [3]. Note that there is no documentation online apart from the code.

The implemenation allows for reading/writing full object graphs, ie. a field in an object referencing another object that is also mapped to JCR would get read/written along the way (storing only the object Id in JCR, but preferable would be the JCR path of the referenced object). The JCR structure was custom (it was XMLish, as we stored XML documents directly in a different part of the code), but a Transformer interface abstracts from the special Java <-> JCR mapping [5].

In the end, we were not so happy with this approach because it seemed to much abstraction from our main API JCR and created yet another caching location (the managed object pool). But we probably added too much abstraction (fully JCR-independent interfaces that were implemented by the annotated objects, yet another Session class, etc.)...

Here is the executive summary of the pros and cons (which you probably know from OCM or JCROM):

Advantages: + full object graphs supported + easy-to-run queries, defined at the object itself + code completion for properties

Disadvantages: - pooling = caching needed - another hard-to-debug abstraction - just a copy of JPA, not using it directly

Regards, Alex

[1] http://www.mindquarry.org/repos/mindquarry-collaboration-server/trunk/mindquarry-persistence/

[2] API: http://www.mindquarry.org/repos/mindquarry-collaboration-server/trunk/mindquarry-persistence/persistence-api/src/main/java/com/mindquarry/persistence/api/

[3] Test code: http://www.mindquarry.org/repos/mindquarry-collaboration-server/trunk/mindquarry-persistence/jcr-persistence/src/test/java/com/mindquarry/persistence/jcr/

[4] Example annotated class: http://www.mindquarry.org/repos/mindquarry-collaboration-server/trunk/mindquarry-persistence/jcr-persistence/src/test/java/com/mindquarry/persistence/jcr/User.java

[5] "Transformers", mapping Java <-> JCR: http://www.mindquarry.org/repos/mindquarry-collaboration-server/trunk/mindquarry-persistence/jcr-persistence/src/main/java/com/mindquarry/persistence/jcr/trafo/

Am 05.02.2008 um 12:48 schrieb David Nuescheler: