Is there an issue regarding persistence of imported XML namespaces with ModeShape 2.8?

[laurent99]

Hi all,

I'm using ModeShape 2.8.3, and I have an issue regarding the XML import (via the Session.importXML() method) and the persistence of XML namespaces. The repository configuration is:

{code:xml}

<?xml version="1.0" encoding="UTF-8"?>

<configuration xmlns:mode="http://www.modeshape.org/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0">

    <!-- The JCR repository definition -->

    <mode:repositories>

        <mode:repository jcr:name="test-repository" mode:source="test-repository-source">

            <mode:options jcr:primaryType="mode:options">

                <mode:option jcr:name="jaasLoginConfigName" mode:value=""/>

            </mode:options>

        </mode:repository>

    </mode:repositories>

    <!-- The repository source definition -->

    <mode:sources>

        <mode:source

              jcr:name="test-repository-source"

              mode:classname="org.modeshape.connector.disk.DiskSource"

              mode:repositoryRootPath="JCR-repository"

              mode:defaultWorkspaceName="test-ws">

        </mode:source>

    </mode:sources>

</configuration>

{code}

When a XML file is imported into the JCR repository (using the Session.importXML() method), the XML namespaces are mapped to JCR namespaces. After the import, if I print the NamespaceRegistry content (at the workspace level), I can check that my XML prefixes are mapped to JCR namespaces with the same prefixes, and these namespaces are associated with their corresponding URIs. So everything is OK.

Then, I re-start the JCR repository (shutdown/startup), and I check again the NamespaceRegistry content. And I can see that, even if my URIs are still there, their corresponding prefixes have changed (now they have default values such as "ns001", "ns002"...). Therefore, when I try to access the XML content, I get errors since the JCR Node names do not match the initial XML elements anymore. Everything looks like the JCR repository does not persist the JCR namespaces that are created from a XML import. Note that if I re-import the XML file, the "default" prefixes are overriden by the correct values. But this would mean that you have to re-load any XML content at each JCR repository startup before using it, which sounds weird...

So, did I miss something, or is there a known bug that relates to such a behavior ?

Thanks for your help.

[rhauch]

I don't know of any issues. The code looks to be correct: the "startPrefixMapping" method is called when a new XML namespace is defined, and when the session's registry does not contain the namespace (which means it's not in the session or the workspace) it is then added to the workspace's registry, which automatically persists the namespaces.

Based upon your short snippet of your repository, your repository configuration is not defining and is thus using an in-memory "system" workspace, which is where all the namespaces (and node types, version histories, and locks) are stored. This means that all of the system content is empty again upon restart, so you definitely want to fix this. See the documentation for details, with suggestions on how to configure properly. You should be able to simply define the "system" workspace in your disk source (or call it whatever you like) and then use the "systemSourceName" repository option to a value of "system@test-repository-source".

We know that this was extremely confusing and a frequent problem for people starting out. We've corrected this in ModeShape 3.x to handle this in a much better way.

Out of curiocity, have you been using ModeShape 2.x for a while? If not, is there a reason you chose it over the latest ModeShape 3.1.1.Final?

[laurent99]

Hi Randall, and thanks for the quick answer !

I've just tried your solution, and it works fine. So thank you very much for your help.

Regarding your question about the ModeShape release we are using, we've been using ModeShape for about one year now, and at that time, ModeShape 3 was only available as a beta release, so we decided to go with ModeShape 2. But we should consider soon to move to ModeShape 3...

And thanks again for your help.