On 2/19/06, Mark Slater <[EMAIL PROTECTED]> wrote: > I'm a bit confused. My understanding of custom types was that they > simply define constraints on the otherwise (relatively) unstructured > nodes, more like defining constraints on your tables (UNIQUE, FOREIGN > KEY, etc) in an RDBMS than user defined types to be stored in the > tables.
Yes, you are right. > Just to be clear, I am not planning to subclass Jackrabbit's > NodeImpl class to add functionality based on the custom types; I'm > not even sure where this would be done because I haven't seen a place > to map JCR repository node type to Java class type. > > Also, when I asked why there wasn't a place to specify custom node > definitions in the repository configuration, the "Reader" I was > referring to would be (currently) either > org.apache.jackrabbit.core.nodetype.xml.NodeTypeReader, or > org.apache.jackrabbit.core.nodetype.compact.CompactNodeTypeDefReader. > Since Jackrabbit knows when it creates the repository for the first > time, it seems far better to let it decide if/when to process a > custom node file. If clients need to add custom types later, they're > on their own. The other possibility that could work well would a > repository initialization hook - a client specified function called > when a repository is created to do one time initialization (custom > node types, initial layout of the default workspace, etc.). Currently Jackrabbit does not provide a simple way of automatiocally registering node types on startup, your application will have to handle this.
