Hi, I favour neither of both :-) I would favor a real node type management API, which would allow more fine grained control over the node type registration process (such an API will be coming with JCR 2).
The Stream based (CND or XML) API is too clunky: I registers all or part or whatever node types in the file, it throws an exception, whose message must be decoded to try to find out what is actually going on. As a result, I like this method for simple first-time node type registration, but it does not suffice it for real-world node type management. So, I would rather like to see some transitional Jackrabbit API, which mimicks, what is currently proposed for JCR 2.0 and may later be easily migrated. Yes, I am in desperate need for real node type management, too :-) Regards Felix Am Samstag, den 11.08.2007, 22:06 +0200 schrieb Christoph Kiehl: > Hi, > > on the user list the question arose whether it is possible to reregister > node types via RMI. Currently JackrabbitNodeTypeManager doesn't expose > NodeTypeManagerImpl.registerNodeTypes(InputStream, String, boolean) > which allows to enable reregistration. > There are two options to implement this feature: > > 1. Extend JackrabbitNodeTypeManager with another method (might be the > signature from above or a "reregister()" methode) > 2. Change the default behaviour of > NodeTypeManagerImpl.registerNodeTypes(InputStream, String) to always try > to reregister node types. > > I'm in favour of option two because > > a) I don't want to add more methods to JackrabbitNodeTypeManager if > avoidable because node type registration will change anyway with JCR 2.0. > b) I think it's more natural. If I try to register a node type I do this > because I want this node type to be registered and not because I want to > check if it is already registered and get an exception back if it is. > There are other ways to find out if a node type is registered. Is there > any reason not just try to reregister existing nodetypes by default? > > Cheers, > Christoph >
