Exporting content into remote JackRabbit

[legolas]

Hi all,

Let me first apologise if I ask a question that has already been raised and answered here, I am a newbie on Alfresco and JCR, searched this forum but didn't find the answer to my question/problem.

I have written an Action that gets triggered when content arives in a published folder.
This action needs to export this content, including children, to a remote JackRabbit repository.
To accomplish this I first followed the tutorial on the wiki and changed the parts I needed to change.
I am able to retrieve the javax.jcr.Node that the NodeRef refers to, also I can export this node to a byte array, as well as openening a connection to the remote JCR.

private void publishNode(Session localSession, Session remoteSession, String path, Node node) {
   try {
      String nodePath = node.getPath();

      ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
      localSession.exportSystemView(nodePath, outputStream, false, false);

      ByteArrayInputStream inputStream = new ByteArrayInputStream(outputStream.toByteArray());

      remoteSession.importXML("/epoline/website/content", inputStream, 
            ImportUUIDBehavior.IMPORT_UUID_COLLISION_REMOVE_EXISTING);
   } catch (RepositoryException e) {
      reportError("Generic repository exception", e, null);
   } catch (IOException e) {
      reportError("Export from local or import to remote repository failed.", e, null);
   }
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

But when I call the import method on the remote Session, I get the following stack:

javax.jcr.nodetype.NoSuchNodeTypeException: {http://www.alfresco.org/model/content/1.0}content
   at org.apache.jackrabbit.rmi.server.ServerObject.getRepositoryException(ServerObject.java:122)
   at org.apache.jackrabbit.rmi.server.ServerSession.importXML(ServerSession.java:243)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
   at sun.rmi.transport.Transport$1.run(Transport.java:153)
   at java.security.AccessController.doPrivileged(Native Method)
   at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
   at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
   at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
   at java.lang.Thread.run(Thread.java:595)
   at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
   at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
   at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
   at org.apache.jackrabbit.rmi.server.ServerSession_Stub.importXML(Unknown Source)
   at org.apache.jackrabbit.rmi.client.ClientSession.importXML(ClientSession.java:260)
   at org.epo.cms.alfresco.executer.PublishActionExecuter.publishNode(PublishActionExecuter.java:169)
   at org.epo.cms.alfresco.executer.PublishActionExecuter.executeImpl(PublishActionExecuter.java:78)‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Can someone please explain what is going wrong here?

Thanks in advance.

Marcel.

[davidc]

Obviously, I would prefer if you were importing from Jackrabbit to Alfresco.

Although, JSR-170 specifies a standard API, it does enforce a standard model.  And that's the problem here.

[legolas]

First of all thanks for your quick answer.

Obviously, I would prefer if you were importing from Jackrabbit to Alfresco.

Well we would like to use Alfresco as our main CMS implementation, but a lightweight repository on the published side, some portlets and other stuff, thereby physically seperating the author repository from the published repository. That's why this export needs to be done.

Although, JSR-170 specifies a standard API, it does enforce a standard model.  And that's the problem here.

I was under the impression that the exportSystemView method would export a complete view of the system including the NodeType's and NameSpace definitions.

If this is not the case, is there a way to accomplish this?

[davidc]

As per the spec, the systemView does not export node type definitions. 
Unfortunately, there's no standard way of registering node types.  That should come in JSR-283 (next update of JSR-170).

So, the only solution is to define equivalent namespaces and node types using the mechanism provided by Jackrabbit.

As for wanting a light-weight published repository, I'm interested in why you prefer Jackrabbit.

[legolas]

We (I adviced) carefully selected alfresco based on requirements, such as JCR compliancy, workflow, etc.
We don't need/want jBPM on the published node, this is the final target of the workflow.
Neither do we want author components on the published node.

JackRabbit is AFAIK, the only released repository only implementation, Jeceira is at quite an early stage.

Where can I find the model def's in alfresco?

I think I just need to make sure the same def's end up in jackrabbit as well.

Thanks,
Marcel

[davidc]

You will find Alfresco model definitions in

<config_dir>/alfresco/model

In particular, contentModel.xml contains the spaces/files model used by the Alfresco web client.

Re: the lightweight "released" repository.  This is an interesting discussion.  I gather from your comments that you perceive Alfresco to be heavier weight than Jackrabbit because it has built-in support for "authoring" such as rules, versioning, workflow etc.  Am I correct in my assumption?

It's possible to switch off the 'author' capability, revealing a vanilla storage and retrieval repository, however, our own benchmarking indicates this is not necessary.  Alfresco will suit your published repository even with all the extra functionality.

[legolas]

Thanks for the information.

It's possible to switch off the 'author' capability, revealing a vanilla storage and retrieval repository, however, our own benchmarking indicates this is not necessary.  Alfresco will suit your published repository even with all the extra functionality.

We did not do any loadtesting just yet. but I reckon that the memory consumption will be a lot higher than a stripped version of alfresco.
Besides, a preferably level one only repository also prevents developers from trying to bypass the overall architecture.

Stripping down alfresco might ease up the synchronization between the CMS and the published repository.
Is stripping down alfresco documented somewhere on the wiki? I did do a brief search but couldn't find it.

Thanks,
Marcel