I'm interested in wy
Stefan Guggisberg wrote:
> On 6/10/05, Stefan Frank <s.frank@vierundsechzig.de> wrote:
>
>>Hi,
>>
>>I'm new to jackrabbit, played a little with magnolia and now want to get my
>>hands dirty with jackrabbit. I intend to use jackrabbit as a repository for
>>digital assets (images, movies in different formats, pdf ...) - it looks
>>like jcr is a perfect fit for this kind of application. After reading all
>>the documents I could find (there is not so much on jackrabbit...), I had my
>>"Hello World!"-experience (node.setProperty("hello", new
>>StringValue("World!"));) - now I want to go all the way. Is there some more
>>documentation somewhere, apart from the jcr-Specification? Up to now, I only
>>found what's on the incubation-website and a brief article on artima.com.
>>
>>Being new to jackrabbit, of course I have lots of questions, eg.
>>
>>- how to define custom-node-types (some explanations on the
>>custom_nodetypes.xml would be nice...)
>
>
> you can register node types by calling
>
> NodeTypeRegistry.registerNodeType(NodeTypeDef).
>
> here's how you get the NodeTypeRegistry object:
>
> Workspace wsp = session.getWorkspace();
> NodeTypeManager ntMgr = wsp.getNodeTypeManager();
> NodeTypeRegistry ntReg =
> ((NodeTypeManagerImpl) ntMgr).getNodeTypeRegistry();
>
> node type registration is not covered by the jsr-170 spec
> but it's nonetheless available in jackrabbit since day 0.
>
> btw: custom_nodetypes.xml should never be manipulated directly;
> otherwise you risk loosing your data.
>
>
>>- what about lazy-loading (what do I get with a node.getNodes(), when each
>>nodes has child nodes - is that configurable?
>
>
> that's nothing you have to worry about. it's up to the repository to
> implement this efficiently.
>
>
>>- what about concurrency? I haven't seen any assumptions about transactional
>>behavior in the jcr - if i got it right, it is up to the repository to
>>ensure that no nodes are deleted by B to which A adds nodes?!
>
>
> check out the jsr 170 specification. transaction support is described in detail.
> another feature to avoid the above descibed scenario is locking.
>
> cheers
> stefan
>
>
>>...
>>
>>Any hints on even the most unfinished documentation would be highly
>>appreciated! (I'll try to write down what you throw at me and maybe will try
>>to compile some how-tos from it...)
>>
>>Cheers
>>Stefan
>>
>>
>
>
|