I'm accessing the repository locally, configured via Spring Modules.
I did some more tinkering and found that the nodes in WS1 and WS2 had
the same UUID as the previous test run of creating the node in Default.
Separating the two actions into two transactions solved the problem. It
would seem that a new node needs to be persisted before you can clone it
to other workspaces.
This quirk could be an artifact of my use of Spring Modules to configure
Jackrabbit.
-Brian
Stefan Guggisberg wrote:
hi brian,
On 2/5/07, Brian Thompson <[EMAIL PROTECTED]> wrote:
Hi all,
I'm trying to work with multiple workspaces in my repository, one
workspace
for each language that the application will support. To create nodes,
I'm
doing
//default workspace
parentNode.addNode("company", "my:Type");
//log in to first workspace
ws1.clone("default", "/company", "/company", true);
//log in to second workspace
ws2.clone("default", "/company", "/company", true);
default: company UUID: 1234-5678
ws1: company UUID: 2468-2468
ws2: company UUID: 2468-2468
According to the javadocs, clone doesn't assign new UUIDs. However,
when I
look up the properties on these nodes, I find that the node in the
default
workspace has one UUID, and the nodes in the other workspaces has a
different UUID!
very strange indeed! the only explanation i can currently think of is
that your
node type my:Type does not include mix:referenceable. but that wouldn't
explain why the corresponding nodes in ws1 & ws2 share the same UUID...
how do you access the repository? locally, using RMI or through JCA?
i quickly tested with jackrabbit running locally, i wasn't able
to reproduce the issue, i.e. all 3 nodes shared the same
UUID.
as you seem to be able to reproduce the issue, please create a jira
issue and ideally provide a small test case that demonstrates the problem.
thanks
stefan
