Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of anchela@day.com designates
 62.192.10.254 as permitted sender)
Message-ID: <489A9925.1010203@day.com>
Date: Thu, 07 Aug 2008 08:41:41 +0200
From: Angela Schreiber <anchela@day.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: users@jackrabbit.apache.org
Subject: Re: what does NodeTypeRegistry.reregisterNodeType() do?
References: <01c601c8ed1a$fca0d330$8119fea9@mercury>
	 <90a8d1c00807240221q2034b4eejed963e12c52b4937@mail.gmail.com>
	 <001301c8edb9$c73cea90$8119fea9@mercury>
	 <90a8d1c00807250143w40527ce6w58ee2f47ccf0e813@mail.gmail.com>
	 <005001c8ee91$1230dd40$8119fea9@mercury>
	 <90a8d1c00807280528v3260e508y4e828742f63fc90b@mail.gmail.com>
	 <001301c8f1a6$d9de5170$2801a8c0@mercury>
 <90a8d1c00807300055w6fcad884k793af2e53b505cfa@mail.gmail.com>
 <48902FF8.7040208@day.com> <005701c8f278$58d090c0$2801a8c0@mercury>
 <009101c8f352$37299900$2801a8c0@mercury> <4898107E.6070504@day.com>
 <01e901c8f735$8ac89e30$2801a8c0@mercury> <489951EE.9000008@day.com>
 <023901c8f815$9b3d32e0$2801a8c0@mercury>
In-Reply-To: <023901c8f815$9b3d32e0$2801a8c0@mercury>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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