jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <ju...@zitting.name>
Subject Re: contrib/jcr-ext proposal
Date Mon, 07 Feb 2005 13:31:39 GMT
Hi all,

Thanks for the comments!

Stefan Guggisberg wrote about o.a.j.ext.xml:
> i rewrote the export methods as they were moved from Workspace to
> Session. the latest implementation internally uses NodeImpl &
> PropertyImpl rather than Node & Property
> for reasons of performance & simplicity: i wanted to avoid extensive &
> redundant String->QName parsing. it will be trivial to change the code
> to just use the standard
> jcr api to make it generic. but for jackrabbit i don't see the point
> in doing so.

I actually looked at your code for inspiration, and my implementation 
follows the same design. (My XML export classes are already available in 
the temporary jcr-ext tree I'm setting up at 
svn://svn.yukatan.fi/public/yukatan/trunk/jcr-ext.) And you are right in 
pointing out the extra trouble with QName handling.

You are also right in that it wouldn't make sense in replacing the 
existing Jackrabbit code with the more general alternatives. The design 
goals for my jcr-ext work are in simple JCR adapters and layers that can 
be wrapped on top of existing repository implementations (both JCR and 

> regarding the import methods:  i agree with david and doubt that you can 
> implement those methods just using the jcr api:
> 1) Workspace.importXML & getContentHandler need to circumvent the transient
> layer and need to write directly to the workspace layer; that's not possible
> with the jcr api
> 2) the semantics of the uuidBehavior flag will be hard if not impossible to
> implement correctly just using the jcr api

You are right in that a truly general XML import mechanism is not 
possible using only the public JCR API. However I'm targetting a 
reasonable subset of the functionality, targeted for simple repositories 
  with a thin or even nonexistent transient layer and hardcoded uuid 
rules (think about most of the small CMS repositories out there). The 
generic XML import classes fit those needs pretty well, and could work 
as a starting point for more complete under-the-hood implementations.

Best regards,

Jukka Zitting

View raw message