Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of stefan.guggisberg@gmail.com
 designates 64.233.170.190 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=ltnK83nPLn47baAAO+NotleYNaBI+Wt3k9uWE2+BkV5NBxwxeBsiV2ENo5Kp/giMaQ
         +EEE8bTAFp7ttq5nO81iMb3SiGRligM+TJroDq3u3k3Ai/Ep/gHBy2hNIseHH3+3QHFf
         fH8WQ1p8Z1QrU/9u3nZFMvySjajKAQL7fqKbs=
Message-ID: <90a8d1c00806040718x3d9ed08eo911ebc08cb4ac22e@mail.gmail.com>
Date: Wed, 4 Jun 2008 16:18:26 +0200
From: "Stefan Guggisberg" <stefan.guggisberg@day.com>
Sender: stefan.guggisberg@gmail.com
To: users@jackrabbit.apache.org
Subject: Re: Namespaces and Session.getImportContentHandler()
In-Reply-To: <20080604155145.8A46.DEV@jeremias-maerki.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20080604155145.8A46.DEV@jeremias-maerki.ch>

On Wed, Jun 4, 2008 at 4:09 PM, Jeremias Maerki <dev@jeremias-maerki.ch> wrote:
> I'm trying to import arbitrary XML content through
> Session.getImportContentHandler(). It works fine if I have XML content
> that is fully in the default namespace. But if there's mixed-namespace content
> I get the following error when calling Session.save():
>
> ERROR - failed to write bundle: 1b773746-508f-4176-ab3f-6bbf3d1b6bd9
> java.lang.IllegalStateException: URI not valid? javax.jcr.NamespaceException: URI http://www.w3.org/1999/02/22-rdf-syntax-ns# is not registered.
>        at org.apache.jackrabbit.core.persistence.bundle.util.NamespaceIndex.stringToIndex(NamespaceIndex.java:55)
>        at org.apache.jackrabbit.core.persistence.bundle.util.ItemStateBinding.writeQName(ItemStateBinding.java:391)
>        at org.apache.jackrabbit.core.persistence.bundle.util.BundleBinding.writeBundle(BundleBinding.java:286)
>        at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.storeBundle(BundleDbPersistenceManager.java:1262)
>        at org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.putBundle(AbstractBundlePersistenceManager.java:703)
>        at org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.store(AbstractBundlePersistenceManager.java:643)
>        at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.store(BundleDbPersistenceManager.java:526)
>        at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:704)
>        at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:873)
>        at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:324)
>        at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:306)
>        at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:300)
>        at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:317)
>        at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1247)
>        at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:897)
> <snip rest of stacktrace/>
>
> It seems like I have to preregister all used namespaces myself with the
> NamespaceRegistry. And I possibly have to do some namespace prefix
> normalization to avoid collisions if I don't have control over what
> namespace prefixes are used because there's only one NamespaceRegistry
> per workspace. Did I get that about right?

no, that shouldn't be necessary, all references namespaces in your xml document
should automatically be registered. seems to be a bug, could you perhaps
provide a sample xml document that fails on import?

cheers
stefan


>
> Thanks for your input,
> Jeremias Maerki
>
>