Performing remote query on a Jackrabbit Server

Question

We are using Jackrabbit 2.2.6 ( webapp) deployed on a Glassfish Application server. We are also building a client to upload files to the server using the rmi interface exposed by the server. We are able to login and upload files using the standard JCR API from the client to the remote server. However, we are having hard time querying the remote server ( we are using JCR-SQL2). Here is the snippet of the code that we are using to query the remote server:

public static List<Node> getNode(Session session, String q) {
    try {
        QueryManager qman = session.getWorkspace().getQueryManager();

        Query query = qman.createQuery(q, Query.JCR_SQL2);
        QueryResult result = query.execute();
        RowIterator rowIt = result.getRows();
        System.err.println("Found results " + rowIt.hasNext());
        List<Node> nList = new LinkedList<Node>();
        while (rowIt.hasNext()) {
            Row row = rowIt.nextRow();
            nList.add(row.getNode());
        }
        return nList;
    } catch (RepositoryException ex) {
        Logger.getLogger(BasicArtifacts.class.getName()).log(Level.SEVERE, null, ex);
    }
    return null;

}

This is what we got when executing the code:

javax.jcr.UnsupportedRepositoryOperationException: TODO: JCRRMI-26
    at org.apache.jackrabbit.rmi.client.ClientRow.getNode(ClientRow.java:70)

It seems like nList.add(row.getNode()); is the culprit. Looks like this is not the best way to do remote query on a Jackrabbit server.

We confirmed that it works on the local transient repository.

While looking through the Jackrabbit code base, we encountered the RemoteQuery and related classes. I tried to write some code - but could not quite make it work. Here is the snippet

public static List<Node> getNode(Session session, String q) throws RemoteException {
    try {
        QueryManager qman = session.getWorkspace().getQueryManager();

        ServerAdapterFactory factory = new ServerAdapterFactory();
        RemoteQueryManager rqman = factory.getRemoteQueryManager(session, qman);
        RemoteQuery rquery = rqman.createQuery(q, Query.JCR_SQL2);
        //this is a basic query - not yet sure how to implement the constraints as yet.
        RemoteQueryResult rresult = rquery.execute();
        RemoteIterator rit = rresult.getRows();


        Object[] objs =  rit.nextObjects();
        System.err.println("Found results " + rit.getSize() );

        List<Node> nList = new LinkedList<Node>();

        for(Object obj:objs){

            //System.err.println(row.getPath());
            ServerRow row = (ServerRow)obj;
            for(Value val:row.getValues()){
                System.err.println("Value:"+ val.getString());
            }
            //How to get the Node out of the ServerRow?
            //nList.add(row.);
        }
        return nList;
    }
    catch (RepositoryException ex) {
        Logger.getLogger(UploadContentToRemote.class.getName()).log(Level.SEVERE, null, ex);

    }
    return null;

}

Any help, pointers will be appreciated. Thanks.

Answer 1

SQL2 was introduced with JSR-283. JSR-283 is not fully supported (yet) through RMI (see JCRRMI-26).

You can either try to reformulate your query in XPATH or use DavEx instead of RMI for remoting.

Answer 2

Have you tried using a NodeIterator:

Query q = queryManager.createQuery(sqlText, Query.JCR_SQL2);
QueryResult result = q.execute();
NodeIterator iter = result.getNodes();
while (iter.hasNext()) {
   nList.add(iter.nextNode());
}

I'm using JackRabbit RMI to CRX backend and this works.

Answer 3

In specific terms of querying, I would recommend that you use the XPath. It's technically deprecated, but seems to be widely used by the community, which means that the implementation is complete and widely used. I suspect that it's more complete in the RMI remote stack as well.

You might already know this, and the other answer alludes to this, but the rmi remoting of jackrabbit doesn't seem to be intended for real usage, as mentioned in threads like this one.

The davex remoting seems to be the preferred way, and, while it's not completely implemented either, there seems to be enough in place to do everything you would need to do.