[ http://issues.apache.org/jira/browse/JCR-324?page=comments#action_12369543 ]
Jukka Zitting commented on JCR-324: ----------------------------------- Mark Slater: > Yes I can do that. I probably won't get to it until the end of the month > though. I'm on a deadline for my own project. Cool, thanks! This would be a nice feature to have in Jackrabbit 1.1. > Create a mechanism allowing Jackrabbit to automatically install custom nodes > when it creates a repository > --------------------------------------------------------------------------------------------------------- > > Key: JCR-324 > URL: http://issues.apache.org/jira/browse/JCR-324 > Project: Jackrabbit > Type: Improvement > Components: config > Reporter: Mark Slater > Priority: Minor > Attachments: customNodeTypeReaderConfig.patch > > The current process for adding new nodes requires clients to open a new > session, get a session, then a workspace, then the Jackrabbit implementation > of a NodeTypeManager where the Jackrabbit NodeTypeDef objects can be added. > However, custom node types need only be added once, preferably when the > repository is created/initialized, as this is the most appropriate time for > such actions. The alternatives for clients wishing to install custom node > types include: > - configuring an object to run when their app is deployed or started; this > method may be dependent on the environment and may not be portable > - checking to see if custom node types exist whenever they go to access the > repository; this degrades performance > A better alternative would be to allow Jackrabbit to add the custom node > types when it creates a repository. This could be accomplished by either > adding an element to the repository configuration XML file. In one scenario, > the element specifies the location of the custom node file and the class of > the node type reader used to process the file. In another scenario, the > element specifies the name of a class and a method to call on that class that > will initialize the repository. In my mind, the first scenario seems like a > better solution. While it is no more portable than a custom initialization > object invoked by the environment, it has the benefit of not being > non-portable code. > I would be happy to code up the first scenario (location of custom node file > and a reader class) if it is an appropriate improvement to the system. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira