You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Alex Lukin <lu...@stu.cn.ua> on 2008/03/16 16:34:46 UTC
What UUID really means in jackrabbit?
Hi, All!
Question is not so simple as it may apear.
Imagine following use case:
Conetnt consists of top node and tree of subnodes, for instance binary attachments. Content may be some OCM object or
whatever other mapping to fixed of flexible but known data structures.
1) User creates some content in his home node and then
2) copies it in incoming node for content editing person. Content editor checks it, may be modifies and
3) moves to some other place where content is published
I think contents 1 and 2 are different but 2 and 3 are the same. UUID identifies some unique node.
So I expect that UUIDs in 1 and 2 must be different, and in 2 and 3 equival.
Questions:
1. Can I expect that move() operation does not change jcr:uuid but copy() does?
2. Can I use UUID to find my conent node independent of its location (path)?
3. How fast is getting node by UUID?
As I told before to Cristophe, path is not a "right thing" for primary key equivalent for OCM, and not "right thing" to refer unque objects.
This use case shows why. So question is: Is UUID good candidate for such unique key? I think yes but I do not know what developers think of :)
--
SY, Alex Lukin
RIPE NIC HDL: LEXA1-RIPE
Re: What UUID really means in jackrabbit?
Posted by Stefan Guggisberg <st...@gmail.com>.
On Sun, Mar 16, 2008 at 4:48 PM, Eugeny N Dzhurinsky <bo...@redwerk.com> wrote:
> On Sun, Mar 16, 2008 at 05:34:46PM +0200, Alex Lukin wrote:
> > 1) User creates some content in his home node and then
> > 2) copies it in incoming node for content editing person. Content editor
> > checks it, may be modifies and
> > 3) moves to some other place where content is published
> >
> > I think contents 1 and 2 are different but 2 and 3 are the same. UUID
> > identifies some unique node. So I expect that UUIDs in 1 and 2 must be
> > different, and in 2 and 3 equival.
> >
> > Questions:
> >
> > 1. Can I expect that move() operation does not change jcr:uuid but copy() does?
>
> Yes, UUID wouldn't be changed on move operations, while copy creates new node
> with new UUID, as stated in API docs
>
>
> > 2. Can I use UUID to find my conent node independent of its location (path)?
>
> Yes, you can.
>
>
> > 3. How fast is getting node by UUID?
>
> As we found, accessing node by UUID usually works much faster than accessing
> the node by the path, however you may find it useful to create some tests and
> give them a try to ensure UUID access is really faster ;)
access by UUID is *the* fastest node retrieval method in jackrabbit ;)
cheers
stefan
>
>
> > As I told before to Cristophe, path is not a "right thing" for primary key
> > equivalent for OCM, and not "right thing" to refer unque objects. This use
> > case shows why. So question is: Is UUID good candidate for such unique key?
> > I think yes but I do not know what developers think of :)
>
> We are using a way of finding content by UUID - not paths in our application,
> and it works just fine.
>
> --
> Eugene N Dzhurinsky
>
Correct way to address remote repository using a URLRemoteRepository?
Posted by Charles Johnson <cj...@proteanit.net>.
My log file reports the rmi uri of the running repository to be the
following (obfuscated):
16.03.2008 15:09:33 *INFO * AbstractConfig: rmiUri:
//hostname:8180/jackrabbit.repository
This is how I'm trying to reach it:
import org.apache.jackrabbit.rmi.repository.URLRemoteRepository;
import javax.jcr.Repository;
import javax.jcr.Session;
public class RemoteContent {
public static void main(String[] args) throws Exception {
Session session = null;
try {
Repository repository = new
URLRemoteRepository("http://hostname:8180/jackrabbit-webapp-1.4");
session = repository.login();
System.out.printf("The username with this session is %s\n",
session.getUserID());
System.out.printf("The workspace for this session is %s\n",
session.getWorkspace());
} finally {
if (session != null) {
session.logout();
}
}
}
}
and this is the result:
log4j:WARN Continuable parsing error 29 and column 23
log4j:WARN The content of element type "log4j:configuration" must match
"(renderer*,appender*,(category|logger)*,root?,categoryFactory?)".
Exception in thread "main" javax.jcr.RepositoryException: Remote
repository not found: The resource at
http://hostname:8180/jackrabbit.repository could not be retrieved:
Unexpected end of file from server: Unexpected end of file from server
at
org.apache.jackrabbit.rmi.repository.URLRemoteRepositoryFactory.getRemoteRepository(URLRemoteRepositoryFactory.java:84)
at
org.apache.jackrabbit.rmi.repository.AbstractRemoteRepositoryFactory.getRepository(AbstractRemoteRepositoryFactory.java:59)
at
org.apache.jackrabbit.commons.repository.ProxyRepository.login(ProxyRepository.java:100)
at
org.apache.jackrabbit.commons.AbstractRepository.login(AbstractRepository.java:41)
at RemoteContent.main(RemoteContent.java:23)
Caused by: java.net.SocketException: Unexpected end of file from server
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:714)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:577)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:711)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:577)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1004)
at java.net.URL.openStream(URL.java:1009)
at
org.apache.jackrabbit.rmi.repository.URLRemoteRepositoryFactory.getRemoteRepository(URLRemoteRepositoryFactory.java:61)
... 4 more
java.net.SocketException: Unexpected end of file from server
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:714)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:577)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:711)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:577)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1004)
at java.net.URL.openStream(URL.java:1009)
at
org.apache.jackrabbit.rmi.repository.URLRemoteRepositoryFactory.getRemoteRepository(URLRemoteRepositoryFactory.java:61)
at
org.apache.jackrabbit.rmi.repository.AbstractRemoteRepositoryFactory.getRepository(AbstractRemoteRepositoryFactory.java:59)
at
org.apache.jackrabbit.commons.repository.ProxyRepository.login(ProxyRepository.java:100)
at
org.apache.jackrabbit.commons.AbstractRepository.login(AbstractRepository.java:41)
at RemoteContent.main(RemoteContent.java:23)
//================================================================================================
I'm really just guessing at this URL. What *should* it be for it to work?
Charles
Re: What UUID really means in jackrabbit?
Posted by Eugeny N Dzhurinsky <bo...@redwerk.com>.
On Sun, Mar 16, 2008 at 05:34:46PM +0200, Alex Lukin wrote:
> 1) User creates some content in his home node and then
> 2) copies it in incoming node for content editing person. Content editor
> checks it, may be modifies and
> 3) moves to some other place where content is published
>
> I think contents 1 and 2 are different but 2 and 3 are the same. UUID
> identifies some unique node. So I expect that UUIDs in 1 and 2 must be
> different, and in 2 and 3 equival.
>
> Questions:
>
> 1. Can I expect that move() operation does not change jcr:uuid but copy() does?
Yes, UUID wouldn't be changed on move operations, while copy creates new node
with new UUID, as stated in API docs
> 2. Can I use UUID to find my conent node independent of its location (path)?
Yes, you can.
> 3. How fast is getting node by UUID?
As we found, accessing node by UUID usually works much faster than accessing
the node by the path, however you may find it useful to create some tests and
give them a try to ensure UUID access is really faster ;)
> As I told before to Cristophe, path is not a "right thing" for primary key
> equivalent for OCM, and not "right thing" to refer unque objects. This use
> case shows why. So question is: Is UUID good candidate for such unique key?
> I think yes but I do not know what developers think of :)
We are using a way of finding content by UUID - not paths in our application,
and it works just fine.
--
Eugene N Dzhurinsky