You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Brian Thompson <el...@gmail.com> on 2007/02/05 22:50:30 UTC
workspace.clone()
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!
While ws1 and ws2's corresponding nodes do have their UUID in common, I need
this to be common to all three workspaces for corresponding nodes.
Has anyone run into this type of thing before?
Regards,
-Brian
Re: workspace.clone()
Posted by Brian Thompson <el...@gmail.com>.
I'll take another look. Thanks for the help!
-Brian
Stefan Guggisberg wrote:
> On 2/8/07, Brian Thompson <el...@gmail.com> wrote:
>> 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.
>
> that's by design. workspace operations like copy, move & clone work
> directly
> on the workspace persistence layer, i.e. they're not affected by transient
> modifications. please refer to the jsr 170 specification for more details,
> specifically section 5.1.1.
>
> cheers
> stefan
>
>>
>> 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 <el...@gmail.com> 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
>>
>
Re: workspace.clone()
Posted by Stefan Guggisberg <st...@gmail.com>.
On 2/8/07, Brian Thompson <el...@gmail.com> wrote:
> 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.
that's by design. workspace operations like copy, move & clone work directly
on the workspace persistence layer, i.e. they're not affected by transient
modifications. please refer to the jsr 170 specification for more details,
specifically section 5.1.1.
cheers
stefan
>
> 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 <el...@gmail.com> 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
>
Re: workspace.clone()
Posted by Brian Thompson <el...@gmail.com>.
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 <el...@gmail.com> 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
Re: workspace.clone()
Posted by Stefan Guggisberg <st...@gmail.com>.
hi brian,
On 2/5/07, Brian Thompson <el...@gmail.com> 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
>
> While ws1 and ws2's corresponding nodes do have their UUID in common, I need
> this to be common to all three workspaces for corresponding nodes.
>
> Has anyone run into this type of thing before?
>
> Regards,
>
> -Brian
>
>