Re: Wondering about JCR
On Mon, 21 Dec 2009, Michael Marth wrote:
I'm wondering ifJCR, aka the Content Repository API for Java, could be
useful to me. I've been reading about it - including reading the spec -
but i'm still not really sure. Does anyone have any hands-on experience
with it?
Yes, me and my colleagues (I work for Day Software that contributed a
lot to the JCR spec and the Jackrabbit reference impl)
Excellent! Thanks for your response - apologies for not replying sooner,
but i wanted to go off and get my hands dirty first. I spent yesterday
playing with Jackrabbit, and i like it so far.
The thing is, my use is not managing anything really document-like, but
There are a number of projects using JCR for non-content mgmt stuff. I
compiled some here:
http://dev.day.com/microsling/content/blogs/main/jcrisformore.html
Several of those are still documentish - images, maven artifacts and
emails all look like kinds of documents to me. Some of the other things
could also be documenty, but it's impossible to tell from a quick look at
their websites. Still, from what i understand of JCR, there seems to be
absolutely no barrier to using it for smaller, more structured objects.
Possibly also images, although those could be handled externally to the
repository.
You might also want to add the images there. JCR repos handle binary and
non-binary content equally well.
Absolutely! And managing that inside the catalogue would definitely be
better from a business user point of view. The only reason i hesitate is
that i probably don't want to put the image data in a repository of any
sort in production, i want to push it out to the webservers at the front
end, so putting it in a repository at the back end makes things more
complicated for me. Simpler for my users, but who cares about them, eh?
Now, on the site itself, this stuff is all read-only, with some simple
access patterns based on individual item lookups plus a few kinds of
query, followed by reading properties from the objects found. Here,
something like JPA or another ORM or OODB approach (or even just POJOs
stored with serialisation) is probably right - there's no need for the
complexity of JPA [i meant JCR - tom].
My advise is to stay from obkect-content-mapping until you think that
you really need it. For JCR repos and Java impedence mismatch between
data and OOP is nowhere as big as it is for relational data. You might
get away by just working on the nodes directly.
I am very dubious indeed about this. I like being able to say:
int listPrice = product.getListPrice();
Rather than:
int listPrice = (int)product.getProperty("listPrice").getLong();
And:
int currentPrice = product.getPrice();
Rather than:
int currentPrice;
boolean isOnSale = product.getProperty("onSale").getBoolean();
if (isOnSale) currentPrice = (int)product.getProperty("salePrice").getLong();
else currentPrice = (int)product.getProperty("listPrice").getLong();
(my point here is that you can't write methods in JCR nodes, so you have
to put your business logic outside the objects where it naturally belongs)
Domain objects need to be real objects. JCR nodes don't cut the mustard.
there's a rather CVS-like model, where there's a single canonical
version of the data, plus a set of workspaces for each user: users can
update their workspace from the canonical version, and commit changes
from their workspace into it, with merge conflicts being detected and
handled. The system maintains a history of these commits, and the
versions of the data that existed at each stage.
While you can use workspaces for that another approach might be to
simply use different branches in one workspace (and set the ACLs such
that each user can only see his own branch). You would have to do the
merge yourself, but the whole setup would be simpler to handle in my
opinion.
Could you expand on why you think that? Writing the merge code myself is
something i'd like to avoid, as it could be very complicated.
btw: "committing" changes could be done by setting an attribute on the
user's node and having a JCR Observer listen for such changes and
distribute them to the other workspaces.
Ah, interesting. Again, i assume this means doing the merge logic myself?
This is all rather more complicated than the 'objects which live in a box'
model embodied by things like JPA. It does, however, seem like a pretty
good fit forJCR, which has these ideas of workspaces, updates, merges,
and so on. Am i right in thinking that?
The things i'm not sure about are:
- WhetherJCRimplementations will work well with large numbers (on the
order of 200 000 items all told) of fairly small items, rather than the
smaller numbers of larger items that are more typical.
This should be no problem. The only issue I am aware of is that the
Jackrabbit implementation does not like too many child nodes (more than,
say, 1000) in the same hierarchy level. Usually, one can design his node
hierarchy to avoid this problem.
Yes, that shouldn't be a problem. Categories may have hundreds of
products, and products may have dozens of SKUs, but there shouldn't be
1000 of anything at any level. Indeed, JPA won't like that any more than
JCR will!
- Whether there's any kind of ready-made generic metadata-driven UI (free
or commercial) for the backoffice server that i can slap on top of my
repository, rather than having to handwrite it.
Not sure about "backoffice server", but there are a number of UIs for
JCRs:
http://dev.day.com/microsling/content/blogs/main/jcrtools.html
Excellent, thank you, this is exactly what i need to look into.
- WhetherJCRimplementations out there actually support the bits of the
workspace and versioning model i need.
Jackrabbit fully implements the spec, so if the model itself is right
for you then Jackrbbit will have you covered.
But then there's the question of whether Jackrabbit is suitable for
production use. Presumably, if it was, there wouldn't be things like CRX,
for which you have to pay some nontrivial dollar.
- Whether, and how,JCRimplementations would let me specify the quite
rigid node type definitions i need. I don't want users to be able to add
random extra properties to items, for instance.
Yes, the node types can be defined as rigid as you like.
Ideal.
In CRX (our commercial version of Jackrabbit) you'll find a user
interface to design node types.
Cool - could be useful for experimentation. In my current master plan, i
need to drive node type definition from metadata elsewhere in the system,
though, so a programmatic interface is what i need. The JSR 283 node type
definition stuff looks perfect, and as soon as JCR 2 is widely supported,
will be portable.
- How i'd handle the push from the backofficeJCRstore to the site's JPA
or whatever, or whether i even would - should i just useJCRat the front
too? The API is much less fun to work with than JPA, but the look of it.
Not sure if I get the question 100% right, but have a look at JCR
listeners. The catch events when sthg in the repository changes and
could be used to push data from the repo to some outside system.
Yes, i'd come to this conclusion too. Attach a listener, do a merge,
convert the events into changes to the foreign system. The only trouble is
that, if i've read the spec right, events only get delivered *after* the
repository changes are committed, ie the transaction ends. That means that
if the changing of the foreign system fails, i'm in a pickle, because it's
to late to roll back the changes to the repository. I guess i could
maintain a pair of branches/workspaces for the foreign system, one of the
goal state, and one of the current state, so i can manually roll back the
JCR repo if the update fails. Or do something else - the manual merge
starts to look more attractive at this point.
- How i'd integrate workflow with the editing and pushing process.
You will have to integrate or develop your own workflow tool, workflow
is not part of JCR.
Yes, that's what i expected.
Having said that, workflow state can easily be handled by setting
property values on nodes.
Aha, good point. I need to learn to think more in terms of how i can make
the nodes work for me.
- That there are N other showstopping problems i haven't even thought of!
Don't know any.
In case you hav not looked at it, yet, check out Apache Sling, which is
an application framework to develop on top of JCRs.
I'd come across it, but not looked into it. I will do, but i'm not keen to
commit to a web framework at this point - i'd like to have an
infrastructure solution that leaves the front-end developers with their
choices open.
tom
--
science fiction, old TV shows, sports, food, New York City topography,
and golden age hiphop