You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Jukka Zitting (JIRA)" <ji...@apache.org> on 2006/03/02 03:00:42 UTC

[jira] Commented: (JCR-324) Create a mechanism allowing Jackrabbit to automatically install custom nodes when it creates a repository

    [ http://issues.apache.org/jira/browse/JCR-324?page=comments#action_12368429 ] 

Jukka Zitting commented on JCR-324:
-----------------------------------

This seems like a nice approach to the repository initialization issue. So far the general opinion has been that things like installing custom node types or importing an initial content structure are separate administrational tasks that should be performed manually after the repository has been created.

Would you be interested in refactoring your approach a bit to make it more general? I was thinking that instead of limiting this feature to just custom node types, it could take care of all sorts of repository initialization. How about something like a general RepositoryInitializer interface?

    public interface RepositoryInitializer {
        void initialize(Session session) throws RepositoryException;
    }

An instance could be configured using an optional <RepositoryInitializer> configuration element. If configured, the initialize method of the initializer instance would be called once with a system session after the other repository initialization has been performed but before any other sessions are created.

For example:

    <RepositoryInitializer class="org.apache.jacrkrabbit.core.init.CustomNodeTypeInitializer">
        <param name="path" value="path/to/custom-nodetypes.xml"/>
    </RepositoryInitializer>

Another example:

    <RepositoryInitializer class="org.apache.jacrkrabbit.core.init.ImportContentInitializer">
        <param name="path" value="path/to/initial-content.xml"/>
    </RepositoryInitializer>

A combined version:

    <RepositoryInitializer class="org.apache.jacrkrabbit.core.init.CombinedInitializer">
        <param name="customNodetypes" value="path/to/custom-nodetypes.xml"/>
        <param name="initialContent" value="path/to/initial-content.xml"/>
    </RepositoryInitializer>


> 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