According to the spec:

The nt:linkedFile node type is similar to nt:file, except that the content node is not stored directly as a child node, but rather is specified by a REFERENCE property. This allows the content node to reside anywhere in the workspace and to be referenced by multiple nt:linkedFile nodes. The content node must be referenceable.

So when you upload & store a new piece of content, you need to make sure that you also add the [mix:referenceable] mixin to the content node (either via your node type definitions or via the API). Once you store a referenceable content node, you should be able to use the [nt:linkedFile] type for other nodes and set the [jcr:content] property as a reference towards the original content node (just like you would set a normal reference):

[nt:linkedFile] > nt:hierarchyNode primaryitem jcr:content

  - jcr:content (reference) mandatory

I am not getting how to give the reference to existing jcr:content node. Could you please give me piece of code explaining that.

contentNode.addMixin("mix:referenceable").

And you set the property on the nt:linkedFile nodes like: node.setProperty("jcr:content", contentNode).

Sorry if this is a bit off topic, is mix:referencable something that is impacting performance?

I'm currently only using that mixin so that I can read jcr:uuid and then use that uuid for soft links on other nodes. Not for assigning nodes to properties as described in your post.

I'm asking, because I'm using mix:referencable a lot, so If that is something that would cause a lot of (unneccessary) processing overhead when creating nodes, I should refactor my code.

I'm currently only using that mixin so that I can read jcr:uuid and then use that uuid for soft links on other nodes. Not for assigning nodes to properties as described in your post.

 

I'm asking, because I'm using mix:referencable a lot, so If that is something that would cause a lot of (unneccessary) processing overhead when creating nodes, I should refactor my code.

Adding a mixin to a node (like "mix:referenceable") is very little overhead - it basically adds the mixin name to the "jcr:mixins" property (which is protected). You're right, though -- there is some.

An alternative that uses none of the overhead is to use the "Node.getIdentifier()" method (added in JCR 2.0) that returns ModeShape's internal identifier for the node. This works on every node, even for nodes that are not referenceable. So, if you're just getting an identifier string to store in a property (of type STRING), you can certainly use the node's identifier instead of a referenceable node's UUID. There's even a method on Session to directly look up the node given an identifier string. (Please consider this string to be opaque; ModeShape uses different patterns for the identifiers strings of different kinds of nodes.)

Yet another alternative is to use a property of type SIMPLEREFERENCE. This is non-standard and specific to ModeShape, but it allows you to get and set the values of the property via Node references. Yes, you still need the referred node to be "mix:referenceable", but it is easier than having to manually get the identifier for the node before setting the identifier string as the value, and manually resolving the string to a Node when getting the value. A SIMPLEREFERENCE is like a WEAKREFERENCE in that referential integrity is not enforced, but there is no backreference from the referred node to the referring node (so it's less overhead).

Thanks for the reply,

I already use Node.getIdentifier(), for creating weak references, the jcr:referencable mixin is only used so that I can use "WHERE jcr:uuid IN" subselect queries. Sorry, the "I'm currently only using that mixin so that I can read jcr:uuid " part was a bit misleading.

So if I understand your answer correctly, not much is happening when just adding the mixin, but rather when adding a node having that mixin to a property (which I don't do). Correct?

So if I understand your answer correctly, not much is happening when just adding the mixin, but rather when adding a node having that mixin to a property (which I don't do). Correct?

Correct. Very little happens when that property is a SIMPLEREFERENCE, but more happens with WEAKREFERENCE and REFERENCE.