hi betty
sorry for the delay.
let me summarize your findings to see if i properly
understood the problem. you have
- jcr2spi running on the spi2dav implementation.
- you register/reregister nodetypes directly on the server side.
- the content-representation of your nodetypes under
/jcr:system/jcr:nodeTypes shows your custom definitions.
- however, the nodetypes exposed through the NodeTypeManager
accessed through session.getWorkspace().getNodeTypeManager() don't
reflect the changes.
is that correct?
if it is i would assume that it is caused by the following
behaviour:
- jcr2spi reads nodetype definitions through the SPI only.
- jcr2spi currently has no possibility to detect changes
made to nodetypes.
- new nodetype definitions will be detected (loaded from the
server) if the nodetype is accessed directly or indirectly.
if my assumption is correct, your reregistered definitions
will only show up, if you create a new client repository.
could you confirm this?
without having thought about it carefully, i's say there are
two possibilities in order to make jcr2spi aware of changes
made to nodetype definitions:
- implement extended JSR 283 nodetype functionality and
mandate that the nodetypes are managed through the JCR
API only.
- add some sort of observation mechanism to detect modifications
to the set of registered nodetypes, e.g. by having an
event listener to /jcr:system/jcr:nodeTypes tree.
however, this would not be garanteed to work, since nodetype
registration is not part of JSR 170 and observation is
an optional feature.
currently i would prefer the first variant.
kind regards
angela
Hi -- I've attached a couple of pieces of code. The servlet is the code
that registers or re-registers the node types. I run it
in the same webapp as jackrabbit, and have it load on startup after
everything else.
The dumpsnippet.java is from a test program that just dumps the nodes.
I call it at the "/jcr.system/jcr.nodeTypes" level
to see all the node types and their properties. This is run via the
spi webdav interface.
I can add node types to the CND file and restart tomcat and all is well,
but adding non-mandatory properties to an
exisiting node type does not seem to do anything.
Thanks
Betty
----- Original Message ----- From: "Betty Chang" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, July 30, 2008 12:13 PM
Subject: Re: what does NodeTypeRegistry.reregisterNodeType() do?
Hi -- I'm doing the nodetype registration on the server side as a
servlet. Originally,
I did it in a separate webapp in the same tomcat server
as the jackrabbit server, then I changed it to a servlet within the
jackrabbit webapp.
I configured the servlet to load on startup after all other startup
servlets. It reads in the .CND file, checks if a nodetype
already exists, and if so, it re-registers it. If not, it just
registers it.
My client programs are able to add to the repository using these
custom node types and they show up under
jcr:system/jcr:nodeTypes in the tree.
I can add a new node type to the CND file, restart the tomcat, and the
new node type shows up in the dump on
the client side.
However, if I add a new property to an existing node type, the new
property does not show up.
I'm not sure why it would be a caching issue, because my client
program is just a little test program that can dump out all
the nodes and I run it fresh everytime.
Betty
----- Original Message ----- From: "Angela Schreiber" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, July 30, 2008 2:10 AM
Subject: Re: what does NodeTypeRegistry.reregisterNodeType() do?
In answer to the protocol question, the remote client uses the spi
webdav
interface
ah, i see. that explains it. this is probably a caching issue of the
spi layer.
the SPI layer does not support nodetype registration
anyway, since this a jackrabbit specific extension
and not part of the JCR API.
how did you register the nodetype?
please feel free to create a jira issue.
before you create an issue, i'd like to understand
how you registered the nodetype.
angela
