what does NodeTypeRegistry.reregisterNodeType() do?

[Alexander Klimetschek]

No, versioning works on node-level. Handling all the node's data
together as one "bundle" (except for long binaries that should go into
the DataStore) is the most efficient way to handle and store typical
JCR data - that's why the bundle persistence managers work that way
(storing one serialized bundle with one node and its properties).

Regards,
Alex

On Mon, Jul 28, 2008 at 7:41 AM, Sangeeta <Sangeeta.shah@...> wrote:

> Hi
>
> I have node type with following structure.
> book:file  and book:folder  extends book:node.
>
> When I make an node as node:file , is it possible to make property of
> book:node non- versionable and property of book:file as versionable.
> Basically user can change name, path title ...without making versions but
> when book:content is changed, node should be versioned.
>
>
>
> [book:node] > nt:base
> - book:name (string) mandatory
> - book:path (string)
> - book:title (string)
> - book:nodeType (string)
> - book:description (string)
> - book:reportID (string)
> - book:createdDate (date)
> - book:publishedDate (date)
> - book:unPublishedDate (date)
> - book:region (string)
> - book:department (string)
> - book:language (string)
> - book:organizationID (string)
> - book:keywords (string)
> - book:securityRoles (string)multiple
>
> [book:file] >  book:node
> - book:content (binary)
> - book:contentTxt (string)
>
>
> [book:folder] >  book:node
> + * = book:file multiple
>
> Thanks
> Sangeeta
>
>

--
Alexander Klimetschek
alexander.klimetschek@...

[Angela Schreiber]

hi betty

> What I ran is:
> http://yourhost:yourport/jackrabbit/server/default/jcr:root/jcr:system/jcr:nodeTypes/edge:file/jcr:propertyDefinition[n]/jcr:name
>  
> to look at all my custom properties, where n is the number of the custom
> property I added.
> I can see all the properties I originally created, but whenever I add
> anything new to the CND file to
> add an additional property to the same "edge:file" nodetype,  the newer
> properties never show up after I restart
> Tomcat and run the URL.    In other words, I can only see the same
> number of properties I first had, and no new ones.

> Is this possibly a bug?

if there is neither exception nor warning in the log while
reregistering the modified nodetypes... i would say so.

> Should I just bite the bullet and look at the code for re-registering
> node types?

that's up to you.
in any case: could you report an issue with jackrabbit-core
including a simple test-cnd (both originally and with the
modification) that illustrates the problem and a step-by-step
description of how you are able to reproduce the problem?

thanks in advance
angela

> Betty
>
>
>
> ----- Original Message ----- From: "Angela Schreiber" <anchela@...>
> To: <users@...>
> Sent: Wednesday, August 06, 2008 11:41 PM
> Subject: Re: what does NodeTypeRegistry.reregisterNodeType() do?
>
>
>> hi
>>
>>> Yes, indeed,  I am saying that saying that the new *property
>>> definitions* are
>>> not reflected  in the content representation of your nodetype
>>> under /jcr:system/jcr:nodeTypes.
>>>
>>> I read this content representation on the client side.
>>>
>>> What does it mean to "refresh the tree"?
>>
>> i meant: Session.refresh(false) or
>> Session.getItem("/jcr:system/jcr:nodeTypes).refresh(false).
>>
>> in jcr2spi this forces the client to re-read the target
>> item and all its subtree from the SPI.
>>
>>> I guess that the related question is, how do I know the
>>> re-registration was successful?
>>
>> basically i would expect the NodeTypeRegistry to throw,
>> if re-registering a node type is not successful... but
>> it seems this is not the case here. right?
>>
>>> I have an idea -- should I try dumping out the /jcr:system  tree on
>>> the server side right after re-registration to see what I get?
>>
>> if that is feasible, please do so. if your are - just by
>> coincidence - running the jackrabbit webapp on the
>> server-side, you can easily do so in a browser:
>>
>> http://yourhost:yourport/jackrabbit/server/default/jcr:root/jcr:system/jcr:nodeTypes/nt:file 
>>
>> > replace 'nt:file' by your nt name
>> > 'jackrabbit', 'server' and 'default' may be different in your
>>   installation if you change the defaults.''
>>
>> if
>> - the property definition is still the old on the server side
>>   i assume that for whatever reason the reregistration was
>>   no successful. could ev. be a bug in core.
>>
>> - the property definition is as expected on the server side
>>   and is not reflect on the client even upon Session.refresh...
>>   then i have to try it myself ;)
>>
>> please post your findings.
>> could you also send the original nodetype definition and the
>> changes you want to make? sometimes things get easier, if we
>> can take a closer look at it or try it out. currently i am
>> only guessing.
>>
>> angela
>>
>
>

[Betty Chang-3]

Hi -- Okay, it turns out I was doing something stupid, which is why it was
not working.  I was going over stuff with a finer tooth
comb before filing a bug or looking at source, and I discovered my error.

I no longer have a problem if I just want to add a new property to a custom
node.

I do notice that I cannot delete an existing one and add a new one, but that
is okay.  We won't try to remove any properties.

Thanks for your help

Betty



----- Original Message -----
From: "Angela Schreiber" <anchela@...>
To: <users@...>
Sent: Tuesday, August 12, 2008 1:51 AM
Subject: Re: what does NodeTypeRegistry.reregisterNodeType() do?

> hi betty
>
>> What I ran is:
>> http://yourhost:yourport/jackrabbit/server/default/jcr:root/jcr:system/jcr:nodeTypes/edge:file/jcr:propertyDefinition[n]/jcr:name
>> to look at all my custom properties, where n is the number of the custom
>> property I added.
>> I can see all the properties I originally created, but whenever I add
>> anything new to the CND file to
>> add an additional property to the same "edge:file" nodetype,  the newer
>> properties never show up after I restart
>> Tomcat and run the URL.    In other words, I can only see the same number
>> of properties I first had, and no new ones.
>
>> Is this possibly a bug?
>
> if there is neither exception nor warning in the log while
> reregistering the modified nodetypes... i would say so.
>
>> Should I just bite the bullet and look at the code for re-registering
>> node types?
>
> that's up to you.
> in any case: could you report an issue with jackrabbit-core
> including a simple test-cnd (both originally and with the
> modification) that illustrates the problem and a step-by-step
> description of how you are able to reproduce the problem?
>
> thanks in advance
> angela
>
>> Betty
>>
>>
>>
>> ----- Original Message ----- From: "Angela Schreiber" <anchela@...>
>> To: <users@...>
>> Sent: Wednesday, August 06, 2008 11:41 PM
>> Subject: Re: what does NodeTypeRegistry.reregisterNodeType() do?
>>
>>
>>> hi
>>>
>>>> Yes, indeed,  I am saying that saying that the new *property
>>>> definitions* are
>>>> not reflected  in the content representation of your nodetype
>>>> under /jcr:system/jcr:nodeTypes.
>>>>
>>>> I read this content representation on the client side.
>>>>
>>>> What does it mean to "refresh the tree"?
>>>
>>> i meant: Session.refresh(false) or
>>> Session.getItem("/jcr:system/jcr:nodeTypes).refresh(false).
>>>
>>> in jcr2spi this forces the client to re-read the target
>>> item and all its subtree from the SPI.
>>>
>>>> I guess that the related question is, how do I know the re-registration
>>>> was successful?
>>>
>>> basically i would expect the NodeTypeRegistry to throw,
>>> if re-registering a node type is not successful... but
>>> it seems this is not the case here. right?
>>>
>>>> I have an idea -- should I try dumping out the /jcr:system  tree on the
>>>> server side right after re-registration to see what I get?
>>>
>>> if that is feasible, please do so. if your are - just by
>>> coincidence - running the jackrabbit webapp on the
>>> server-side, you can easily do so in a browser:
>>>
>>> http://yourhost:yourport/jackrabbit/server/default/jcr:root/jcr:system/jcr:nodeTypes/nt:file
>>> > replace 'nt:file' by your nt name
>>> > 'jackrabbit', 'server' and 'default' may be different in your
>>>   installation if you change the defaults.''
>>>
>>> if
>>> - the property definition is still the old on the server side
>>>   i assume that for whatever reason the reregistration was
>>>   no successful. could ev. be a bug in core.
>>>
>>> - the property definition is as expected on the server side
>>>   and is not reflect on the client even upon Session.refresh...
>>>   then i have to try it myself ;)
>>>
>>> please post your findings.
>>> could you also send the original nodetype definition and the
>>> changes you want to make? sometimes things get easier, if we
>>> can take a closer look at it or try it out. currently i am
>>> only guessing.
>>>
>>> angela
>>>
>>
>>
>
>