Well, I think one thing is that "nt:resource" node type is no longer referenceable in JCR 2.0. Note that it was in JCR 1.0, and I'm not sure why they changed it. However, you can easily add the "mix:referenceable" mixin to your content node.
Unfortunately, you're using the file system connector. While our file system connector can be configured to support extra properties (such as 'jcr:mixinTypes'), it does not currently support looking up 'nt:file', 'nt:folder', or 'nt:resource' nodes by their UUID. We could probably add some logic inside the Property.getNode() implementations to use the query indexes to find out which node has that UUID, and then use the connector to look up the node. If that is something you'd like to see, please log an enhancement request in our JIRA. We'll probably be releasing 2.6.0.Beta2 in the next few days, but 2.6.0.Final will be coming in just a few weeks. We could try to get it implemented in 2.6.0.Final.
Oh, in addition to the file system connector that is designed to provide JCR access to an existing directory structure, ModeShape 2.6.0.Beta1 introduced a new "disk-based connector" that is more like the JPA and Infinispan connectors in that it can store any content and persist it as (binary) files on the file system. Note that this connector does optimize 'nt:file' and 'nt:resource' nodes a bit, in that the 'jcr:content' BINARY property on the 'nt:resource' nodes are stored as separate files (based upon the SHA-1 hashes of the content). Performance is also excellent.
So if you are using the file system connector merely to persist files on disk and don't really need the persisted files/folders to have the same structure as the JCR content, then take a look at the disk-based connector.
Thanks for the reply Randall. I need the file system connector because the files are huge (10 GB+) video files, and need to be created outside of Modeshape (e.g. uploaded via FTP) and subsequently served outside of Modeshape (HTTP or streaming media server) directly from the file system. But once they are created, and visible through Modeshape, then all moving and deleting occurs though Modeshape.
That would be great if you could make it so that the filesystem connector supported mix:referenceable nodes. I would imagine this should be optional, since it depends upon whether movement or deletion of files directly on the filesystem can be prohibited. It seems like what is required is the generation of the UUID the first time the node is accessed, and storing it and the path in the Lucene index. Then whenever a node is moved or deleted, the index is updated. Lookup of the node path by UUID is then accomplished by Lucene lookup. The identifiers for the nodes are then UUIDs like the nodes on other connectors, not just the paths. It would be really great if, say, when this option was enabled, instead of the filesystem connector using nt:folder, nt:file, and nt:resource nodes, which are not mix:referenceable, that the nodes had an already registered type which does have mix:referenceable, e.g.:
[mode:folder] > nt:folder, mix:referenceable
[mode:file] > nt:file, mix:referenceable
[mode:resource] > nt:resource, mix:referenceable.
I'll create the JIRA.
Thanks for the correction on nt:resource being not being referenceable. I confess I just quickly looked at this http://wiki.apache.org/jackrabbit/nt%3Aresource which is apparently out of date.
Thanks, Jonathon, for logging that feature request.
Your feature (MODE-1232) has been implemented and merged into our 'master' branch, and will appear in the 2.6.0.Beta2 release that is due later today or tomorrow. Please let us know if you find any problems with the functionality.
Thanks for the very quick turnaround. I will try it out when Beta2 is available.
This should provide me with exactly what I need for the audio-visual content management application that I am developing.