Jackrabbit Content Repository
  1. Jackrabbit Content Repository
  2. JCR-888

javax.jcr.NamespaceException: : is not a registered namespace uri

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.3, 1.3
    • Fix Version/s: 2.1.2, 2.2
    • Component/s: jackrabbit-core
    • Labels:
      None
    • Environment:
      IBM JVM 1.6

      Description

      Using the first hops with both versions 1.2.3 and 1.3, the repository is created successfully the first time it is run. Subsequent attempts to login result in a javax.jcr.NamespaceException.

      DEBUG - Initializing transient repository
      INFO - Starting repository...
      INFO - LocalFileSystem initialized at path repository\repository
      Exception in thread "main" javax.jcr.NamespaceException: : is not a registered namespace uri.
      at org.apache.jackrabbit.core.NamespaceRegistryImpl.getPrefix(NamespaceRegistryImpl.java:538)
      at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.checkNamespace(NodeTypeRegistry.java:1292)
      at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.validateNodeTypeDef(NodeTypeRegistry.java:1415)
      at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.internalRegister(NodeTypeRegistry.java:1221)
      at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.<init>(NodeTypeRegistry.java:671)
      at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.create(NodeTypeRegistry.java:118)
      at org.apache.jackrabbit.core.RepositoryImpl.createNodeTypeRegistry(RepositoryImpl.java:571)
      at org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:262)
      at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:584)
      at org.apache.jackrabbit.core.TransientRepository$2.getRepository(TransientRepository.java:245)
      at org.apache.jackrabbit.core.TransientRepository.startRepository(TransientRepository.java:265)
      at org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:333)
      at org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:388)
      at testing.FirstHops.main(FirstHops.java:24)

      1. aix-namespace.patch
        14 kB
        Chris Schmidt
      2. NamespaceRegistryImpl.java
        21 kB
        Paul Slattery
      3. NamespaceRegistryImpl.java.patch
        0.6 kB
        Rohnny Moland

        Activity

        Hide
        Stefan Guggisberg added a comment -

        i tested with the FirstHop sample found here: http://jackrabbit.apache.org/doc/hops/FirstHop.java

        i was unable to reproduce the issue.

        could you please attach the soruce code of your FirstHops class?

        Show
        Stefan Guggisberg added a comment - i tested with the FirstHop sample found here: http://jackrabbit.apache.org/doc/hops/FirstHop.java i was unable to reproduce the issue. could you please attach the soruce code of your FirstHops class?
        Hide
        Dave Erickson added a comment -

        Thanks for the quick response. I found out that the issue was due to a custom JRE. When I used the default 1.4.2 and 5.0 JRE's from Sun, there is no longer an issue. I will close this ticket.

        Show
        Dave Erickson added a comment - Thanks for the quick response. I found out that the issue was due to a custom JRE. When I used the default 1.4.2 and 5.0 JRE's from Sun, there is no longer an issue. I will close this ticket.
        Hide
        Dave Erickson added a comment -

        This does not occur when the default 1.4.2_11 and 5.0 JRE's are used. It was only happening when using a custom JRE

        Show
        Dave Erickson added a comment - This does not occur when the default 1.4.2_11 and 5.0 JRE's are used. It was only happening when using a custom JRE
        Hide
        Rohnny Moland added a comment -

        I assume that Dave got this exception when using the ibm vm. Is that right, Dave?

        We have the same problem when we try to deploy jackrabbit to websphere application server with ibm vm. The problem is that ibm and sun have different interpretations of what a properties file can contain. With sun vm it is legal to have an empty key, but with ibm vm this is not allowed. When jackrabbit tries to load the ns_reg.properties and ns_idx.properties files from disk, the ibm vm fails with the exception over because if contains something like "=1". See org.apache.jackrabbit.NamespaceRegistryImpl.load(). The easy fix is just to add the empty name space to the map after loading the properties file, which is included in a patch.

        I hope this can be included in the next version of jackrabbit-core.

        Show
        Rohnny Moland added a comment - I assume that Dave got this exception when using the ibm vm. Is that right, Dave? We have the same problem when we try to deploy jackrabbit to websphere application server with ibm vm. The problem is that ibm and sun have different interpretations of what a properties file can contain. With sun vm it is legal to have an empty key, but with ibm vm this is not allowed. When jackrabbit tries to load the ns_reg.properties and ns_idx.properties files from disk, the ibm vm fails with the exception over because if contains something like "=1". See org.apache.jackrabbit.NamespaceRegistryImpl.load(). The easy fix is just to add the empty name space to the map after loading the properties file, which is included in a patch. I hope this can be included in the next version of jackrabbit-core.
        Hide
        Dave Erickson added a comment -

        Hi,

        Yes, it was the IBM JVM that was causing the problem. I was actually
        using jackrabbit inside Lotus Expeditor. The solution was to switch out
        the JVM for the SUN one.

        Dave Erickson
        Sr. IT Specialist
        Software Services for Lotus
        IBM Software Group
        Cell: 858-472-3293
        Email: dave_erickson@us.ibm.com

        From:
        "Rohnny Moland (JIRA)" <jira@apache.org>
        To:
        dave_erickson@us.ibm.com
        Date:
        04/01/2008 12:34 PM
        Subject:
        [jira] Commented: (JCR-888) javax.jcr.NamespaceException: : is not a
        registered namespace uri

        [
        https://issues.apache.org/jira/browse/JCR-888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584266#action_12584266
        ]

        Rohnny Moland commented on JCR-888:
        -----------------------------------

        I assume that Dave got this exception when using the ibm vm. Is that
        right, Dave?

        We have the same problem when we try to deploy jackrabbit to websphere
        application server with ibm vm. The problem is that ibm and sun have
        different interpretations of what a properties file can contain. With sun
        vm it is legal to have an empty key, but with ibm vm this is not allowed.
        When jackrabbit tries to load the ns_reg.properties and ns_idx.properties
        files from disk, the ibm vm fails with the exception over because if
        contains something like "=1". See
        org.apache.jackrabbit.NamespaceRegistryImpl.load(). The easy fix is just
        to add the empty name space to the map after loading the properties file,
        which is included in a patch.

        I hope this can be included in the next version of jackrabbit-core.

        created successfully the first time it is run. Subsequent attempts to
        login result in a javax.jcr.NamespaceException.
        registered namespace uri.
        org.apache.jackrabbit.core.NamespaceRegistryImpl.getPrefix(NamespaceRegistryImpl.java:538)
        org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.checkNamespace(NodeTypeRegistry.java:1292)
        org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.validateNodeTypeDef(NodeTypeRegistry.java:1415)
        org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.internalRegister(NodeTypeRegistry.java:1221)
        org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.<init>(NodeTypeRegistry.java:671)
        org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.create(NodeTypeRegistry.java:118)
        org.apache.jackrabbit.core.RepositoryImpl.createNodeTypeRegistry(RepositoryImpl.java:571)
        org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:262)
        org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:584)
        org.apache.jackrabbit.core.TransientRepository$2.getRepository(TransientRepository.java:245)
        org.apache.jackrabbit.core.TransientRepository.startRepository(TransientRepository.java:265)
        org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:333)
        org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:388)


        This message is automatically generated by JIRA.
        -
        You can reply to this email to add a comment to the issue online.

        Show
        Dave Erickson added a comment - Hi, Yes, it was the IBM JVM that was causing the problem. I was actually using jackrabbit inside Lotus Expeditor. The solution was to switch out the JVM for the SUN one. Dave Erickson Sr. IT Specialist Software Services for Lotus IBM Software Group Cell: 858-472-3293 Email: dave_erickson@us.ibm.com From: "Rohnny Moland (JIRA)" <jira@apache.org> To: dave_erickson@us.ibm.com Date: 04/01/2008 12:34 PM Subject: [jira] Commented: ( JCR-888 ) javax.jcr.NamespaceException: : is not a registered namespace uri [ https://issues.apache.org/jira/browse/JCR-888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584266#action_12584266 ] Rohnny Moland commented on JCR-888 : ----------------------------------- I assume that Dave got this exception when using the ibm vm. Is that right, Dave? We have the same problem when we try to deploy jackrabbit to websphere application server with ibm vm. The problem is that ibm and sun have different interpretations of what a properties file can contain. With sun vm it is legal to have an empty key, but with ibm vm this is not allowed. When jackrabbit tries to load the ns_reg.properties and ns_idx.properties files from disk, the ibm vm fails with the exception over because if contains something like "=1". See org.apache.jackrabbit.NamespaceRegistryImpl.load(). The easy fix is just to add the empty name space to the map after loading the properties file, which is included in a patch. I hope this can be included in the next version of jackrabbit-core. created successfully the first time it is run. Subsequent attempts to login result in a javax.jcr.NamespaceException. registered namespace uri. org.apache.jackrabbit.core.NamespaceRegistryImpl.getPrefix(NamespaceRegistryImpl.java:538) org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.checkNamespace(NodeTypeRegistry.java:1292) org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.validateNodeTypeDef(NodeTypeRegistry.java:1415) org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.internalRegister(NodeTypeRegistry.java:1221) org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.<init>(NodeTypeRegistry.java:671) org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.create(NodeTypeRegistry.java:118) org.apache.jackrabbit.core.RepositoryImpl.createNodeTypeRegistry(RepositoryImpl.java:571) org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:262) org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:584) org.apache.jackrabbit.core.TransientRepository$2.getRepository(TransientRepository.java:245) org.apache.jackrabbit.core.TransientRepository.startRepository(TransientRepository.java:265) org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:333) org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:388) – This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
        Hide
        Stefan Guggisberg added a comment -

        reopening issue...

        Rohnny,
        thanks for sharing this valuable information and providing a patch!

        unfortunately i don't have an ibm jvm at hand and therefore can't test it.
        is this ibm issue (handling of empty strings in java.util.Properties) documented
        anywhere? i couldn't find any related information.

        the fix will probably be slightly more complicated than the one you proposing.
        the index file handling needs to be reviewed as well. if e.g. an index value n
        is assigned to the empty uri this information must not be lost on restart since
        the index value might be referenced by a persisted item state.

        Show
        Stefan Guggisberg added a comment - reopening issue... Rohnny, thanks for sharing this valuable information and providing a patch! unfortunately i don't have an ibm jvm at hand and therefore can't test it. is this ibm issue (handling of empty strings in java.util.Properties) documented anywhere? i couldn't find any related information. the fix will probably be slightly more complicated than the one you proposing. the index file handling needs to be reviewed as well. if e.g. an index value n is assigned to the empty uri this information must not be lost on restart since the index value might be referenced by a persisted item state.
        Hide
        Rohnny Moland added a comment -

        Sorry for late reply.

        I have not found any documentation for it. Mainly it is just a different interpretation about what a properties file can contain. The easy fix would be to just remove serializing of properties with empty key. If you serialize the word "empty" as the property key and then load the property it will work.

        The IBM JVM is free to download here:
        http://www.ibm.com/developerworks/java/jdk/index.html

        If you want to reproduce it, create a properties file with an empty key, load up the properties file and print the properties to the screen. I have only tried to reproduce the issue in ibm java 6, but I assume it has always been like that.

        Show
        Rohnny Moland added a comment - Sorry for late reply. I have not found any documentation for it. Mainly it is just a different interpretation about what a properties file can contain. The easy fix would be to just remove serializing of properties with empty key. If you serialize the word "empty" as the property key and then load the property it will work. The IBM JVM is free to download here: http://www.ibm.com/developerworks/java/jdk/index.html If you want to reproduce it, create a properties file with an empty key, load up the properties file and print the properties to the screen. I have only tried to reproduce the issue in ibm java 6, but I assume it has always been like that.
        Hide
        Rohnny Moland added a comment -

        I looked at the jackrabbit code now, and it seems like the only other class you need to change is org.apache.jackrabbit.core.query.lucene.FileBasedNamespaceMappings.java, right? I havent created a patch, but you have to change the load and store methods. If the namespace prefix is empty, you need to substitute it with some string value for the empty ns string during load/store.

        Show
        Rohnny Moland added a comment - I looked at the jackrabbit code now, and it seems like the only other class you need to change is org.apache.jackrabbit.core.query.lucene.FileBasedNamespaceMappings.java, right? I havent created a patch, but you have to change the load and store methods. If the namespace prefix is empty, you need to substitute it with some string value for the empty ns string during load/store.
        Hide
        Ludo Cuypers added a comment -

        We have a similar problem: We are currently setting up an environment to test the porting of an existing Linux application from a Linux/SUN/X86 platform to a SUSE release 10 SLES z/Linux. This application uses the APACHE / JACKRABBIT content repository. At start-up we receive following messages: (see ATT lepus_jackrabbit20090120.log) .
        The IBM JVM (JVM - version jvmxz6460-20081105_25433) is installed on a S390x z/Linux 2.6.16.54-0.2.10-default with APACHE TOMCAT 5.5.20 and jackrabbit core-1.4.5/

        20/01/2009 13:48:50,557 ERROR org.apache.jackrabbit.core.RepositoryImpl - failed to start Repository: : is not a registered namespace uri.
        javax.jcr.NamespaceException: : is not a registered namespace uri.
        at org.apache.jackrabbit.core.NamespaceRegistryImpl.getPrefix(NamespaceRegistryImpl.java:441)
        at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.checkNamespace(NodeTypeRegistry.java:1368)
        at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.validateNodeTypeDef(NodeTypeRegistry.java:1491)
        at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.internalRegister(NodeTypeRegistry.java:1297)
        at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.<init>(NodeTypeRegistry.java:758)
        at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.create(NodeTypeRegistry.java:120)
        at org.apache.jackrabbit.core.RepositoryImpl.createNodeTypeRegistry(RepositoryImpl.java:605)
        at org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:282)
        at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:618)
        at org.springmodules.jcr.jackrabbit.RepositoryFactoryBean.createRepository(RepositoryFactoryBean.java:57)
        at org.springmodules.jcr.RepositoryFactoryBean.afterPropertiesSet(RepositoryFactoryBean.java:57)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1368)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1334)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
        at java.security.AccessController.doPrivileged(AccessController.java:224)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
        at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:221)
        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185)
        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:423)
        at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:729)
        at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:381)
        at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:139)
        at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:93)
        at be.cipal.business.spring.SpringConfigurator.getApplicationContext(SpringConfigurator.java:43)
        at be.cipal.lepus.business.SpringConfiguratorApplication.getApplicationContext(SpringConfiguratorApplication.java:38)
        at be.cipal.lepus.web.plugin.ApplicationInit.init(ApplicationInit.java:76)
        at org.apache.struts.action.ActionServlet.initModulePlugIns(ActionServlet.java:871)
        at org.apache.struts.action.ActionServlet.init(ActionServlet.java:359)
        at javax.servlet.GenericServlet.init(GenericServlet.java:211)
        at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105)
        at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932)
        at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3951)
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:4225)
        at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
        at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
        at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
        at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809)
        at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:698)
        at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472)
        at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122)
        at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
        at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
        at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021)
        at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
        at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
        at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
        at org.apache.catalina.core.StandardService.start(StandardService.java:450)
        at org.apache.catalina.core.StandardServer.start(StandardServer.java:709)
        at org.apache.catalina.startup.Catalina.start(Catalina.java:551)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
        at java.lang.reflect.Method.invoke(Method.java:599)
        at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432)

        Show
        Ludo Cuypers added a comment - We have a similar problem: We are currently setting up an environment to test the porting of an existing Linux application from a Linux/SUN/X86 platform to a SUSE release 10 SLES z/Linux. This application uses the APACHE / JACKRABBIT content repository. At start-up we receive following messages: (see ATT lepus_jackrabbit20090120.log) . The IBM JVM (JVM - version jvmxz6460-20081105_25433) is installed on a S390x z/Linux 2.6.16.54-0.2.10-default with APACHE TOMCAT 5.5.20 and jackrabbit core-1.4.5/ 20/01/2009 13:48:50,557 ERROR org.apache.jackrabbit.core.RepositoryImpl - failed to start Repository: : is not a registered namespace uri. javax.jcr.NamespaceException: : is not a registered namespace uri. at org.apache.jackrabbit.core.NamespaceRegistryImpl.getPrefix(NamespaceRegistryImpl.java:441) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.checkNamespace(NodeTypeRegistry.java:1368) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.validateNodeTypeDef(NodeTypeRegistry.java:1491) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.internalRegister(NodeTypeRegistry.java:1297) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.<init>(NodeTypeRegistry.java:758) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.create(NodeTypeRegistry.java:120) at org.apache.jackrabbit.core.RepositoryImpl.createNodeTypeRegistry(RepositoryImpl.java:605) at org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:282) at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:618) at org.springmodules.jcr.jackrabbit.RepositoryFactoryBean.createRepository(RepositoryFactoryBean.java:57) at org.springmodules.jcr.RepositoryFactoryBean.afterPropertiesSet(RepositoryFactoryBean.java:57) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1368) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1334) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409) at java.security.AccessController.doPrivileged(AccessController.java:224) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:221) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:423) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:729) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:381) at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:139) at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:93) at be.cipal.business.spring.SpringConfigurator.getApplicationContext(SpringConfigurator.java:43) at be.cipal.lepus.business.SpringConfiguratorApplication.getApplicationContext(SpringConfiguratorApplication.java:38) at be.cipal.lepus.web.plugin.ApplicationInit.init(ApplicationInit.java:76) at org.apache.struts.action.ActionServlet.initModulePlugIns(ActionServlet.java:871) at org.apache.struts.action.ActionServlet.init(ActionServlet.java:359) at javax.servlet.GenericServlet.init(GenericServlet.java:211) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1105) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:932) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3951) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4225) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:698) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) at org.apache.catalina.core.StandardService.start(StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:599) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432)
        Hide
        Paul Slattery added a comment -

        Hi ,
        I am also experiencing this issue indirectly by a project that uses the JackRabbit library.
        I'm sorry , but I don't accept that the solution to this is to change JDK. We are currently using IBM SDK on Z linux and this is not an option for us.
        I have made an attempt to fix this in the code , but one unit test is still failing.
        Also , can someone please explain why these property files have null entry keys ? It seems to be a strange and non-semantic approach to achieve this configuration.

        Paul

        Show
        Paul Slattery added a comment - Hi , I am also experiencing this issue indirectly by a project that uses the JackRabbit library. I'm sorry , but I don't accept that the solution to this is to change JDK. We are currently using IBM SDK on Z linux and this is not an option for us. I have made an attempt to fix this in the code , but one unit test is still failing. Also , can someone please explain why these property files have null entry keys ? It seems to be a strange and non-semantic approach to achieve this configuration. Paul
        Hide
        Paul Slattery added a comment -

        Here is my attempt to fix this issue attached.
        The associated patch did not seem to work for me. As stated one unit test is still failing. (see below)
        Unfortunately I do not have enough time to look further into this issue , perhaps this may be a starting point for someone else.

        Paul

        ----------

        -------------------------------------------------------
        T E S T S
        -------------------------------------------------------
        Running org.apache.jackrabbit.core.util.TestAll
        Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.827 sec
        Running org.apache.jackrabbit.core.nodetype.compact.TestAll
        Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.186 sec
        Running org.apache.jackrabbit.core.xml.TestAll
        Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 22.015 sec <<< FAILURE!
        Running org.apache.jackrabbit.core.query.TestAll
        Tests run: 113, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 31.075 sec
        Running org.apache.jackrabbit.core.observation.TestAll
        Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.155 sec
        Running org.apache.jackrabbit.core.config.TestAll
        Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.577 sec
        Running org.apache.jackrabbit.core.nodetype.xml.TestAll
        Tests run: 34, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.547 sec
        Running org.apache.jackrabbit.core.TestAll
        Tests run: 34, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.811 sec
        Running org.apache.jackrabbit.core.state.TestAll
        Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.622 sec
        Running org.apache.jackrabbit.core.data.TestAll
        javax.jcr.NamespaceException: nt: is not a registered namespace uri.
        at org.apache.jackrabbit.core.NamespaceRegistryImpl.getPrefix(NamespaceRegistryImpl.java:538)
        at org.apache.jackrabbit.core.LocalNamespaceMappings.getPrefix(LocalNamespaceMappings.java:193)
        at org.apache.jackrabbit.core.xml.ImportHandler.startDocument(ImportHandler.java:121)
        at org.apache.jackrabbit.commons.DefaultContentHandler.startDocument(DefaultContentHandler.java:199)
        at org.apache.xerces.parsers.AbstractSAXParser.startDocument(Unknown Source)
        at org.apache.xerces.impl.dtd.XMLDTDValidator.startDocument(Unknown Source)
        at org.apache.xerces.impl.XMLDocumentScannerImpl.startEntity(Unknown Source)
        at org.apache.xerces.impl.XMLVersionDetector.startDocumentParsing(Unknown Source)
        at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
        at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
        at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
        at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
        at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
        at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
        at org.apache.jackrabbit.commons.DefaultContentHandler.parse(DefaultContentHandler.java:82)
        at org.apache.jackrabbit.commons.AbstractSession.importXML(AbstractSession.java:125)
        at org.apache.jackrabbit.core.data.ExportImportTest.doTestExportImportBinary(ExportImportTest.java:64)
        at org.apache.jackrabbit.core.data.ExportImportTest.testExportImportBinary(ExportImportTest.java:39)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at junit.framework.TestCase.runTest(TestCase.java:154)
        at junit.framework.TestCase.runBare(TestCase.java:127)
        at junit.framework.TestResult$1.protect(TestResult.java:106)
        at junit.framework.TestResult.runProtected(TestResult.java:124)
        at junit.framework.TestResult.run(TestResult.java:109)
        at junit.framework.TestCase.run(TestCase.java:118)
        at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:406)
        at junit.framework.TestSuite.runTest(TestSuite.java:208)
        at junit.framework.TestSuite.run(TestSuite.java:203)
        at junit.framework.TestSuite.runTest(TestSuite.java:208)
        at junit.framework.TestSuite.run(TestSuite.java:203)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
        at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
        at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
        at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
        at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
        Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.855 sec <<< FAILURE!

        Results :

        Failed tests:
        testExportImportBinary(org.apache.jackrabbit.core.data.ExportImportTest)

        Tests in error:
        testTwoMixins(org.apache.jackrabbit.core.xml.DocumentViewTest)

        Tests run: 229, Failures: 1, Errors: 1, Skipped: 0

        [INFO] ------------------------------------------------------------------------
        [ERROR] BUILD FAILURE
        [INFO] ------------------------------------------------------------------------
        [INFO] There are test failures.

        Please refer to C:\AdminFolder\jackrabbit149\jackrabbit-core-1.4.9\target\surefire-reports for the individual test results.
        [INFO] ------------------------------------------------------------------------
        [INFO] For more information, run Maven with the -e switch
        [INFO] ------------------------------------------------------------------------
        [INFO] Total time: 1 minute 43 seconds
        [INFO] Finished at: Mon Apr 06 16:41:39 BST 2009
        [INFO] Final Memory: 16M/39M
        [INFO] ------------------------------------------------------------------------

        Show
        Paul Slattery added a comment - Here is my attempt to fix this issue attached. The associated patch did not seem to work for me. As stated one unit test is still failing. (see below) Unfortunately I do not have enough time to look further into this issue , perhaps this may be a starting point for someone else. Paul ---------- ------------------------------------------------------- T E S T S ------------------------------------------------------- Running org.apache.jackrabbit.core.util.TestAll Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.827 sec Running org.apache.jackrabbit.core.nodetype.compact.TestAll Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.186 sec Running org.apache.jackrabbit.core.xml.TestAll Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 22.015 sec <<< FAILURE! Running org.apache.jackrabbit.core.query.TestAll Tests run: 113, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 31.075 sec Running org.apache.jackrabbit.core.observation.TestAll Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.155 sec Running org.apache.jackrabbit.core.config.TestAll Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.577 sec Running org.apache.jackrabbit.core.nodetype.xml.TestAll Tests run: 34, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.547 sec Running org.apache.jackrabbit.core.TestAll Tests run: 34, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.811 sec Running org.apache.jackrabbit.core.state.TestAll Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.622 sec Running org.apache.jackrabbit.core.data.TestAll javax.jcr.NamespaceException: nt: is not a registered namespace uri. at org.apache.jackrabbit.core.NamespaceRegistryImpl.getPrefix(NamespaceRegistryImpl.java:538) at org.apache.jackrabbit.core.LocalNamespaceMappings.getPrefix(LocalNamespaceMappings.java:193) at org.apache.jackrabbit.core.xml.ImportHandler.startDocument(ImportHandler.java:121) at org.apache.jackrabbit.commons.DefaultContentHandler.startDocument(DefaultContentHandler.java:199) at org.apache.xerces.parsers.AbstractSAXParser.startDocument(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.startDocument(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl.startEntity(Unknown Source) at org.apache.xerces.impl.XMLVersionDetector.startDocumentParsing(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source) at org.apache.jackrabbit.commons.DefaultContentHandler.parse(DefaultContentHandler.java:82) at org.apache.jackrabbit.commons.AbstractSession.importXML(AbstractSession.java:125) at org.apache.jackrabbit.core.data.ExportImportTest.doTestExportImportBinary(ExportImportTest.java:64) at org.apache.jackrabbit.core.data.ExportImportTest.testExportImportBinary(ExportImportTest.java:39) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:406) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.855 sec <<< FAILURE! Results : Failed tests: testExportImportBinary(org.apache.jackrabbit.core.data.ExportImportTest) Tests in error: testTwoMixins(org.apache.jackrabbit.core.xml.DocumentViewTest) Tests run: 229, Failures: 1, Errors: 1, Skipped: 0 [INFO] ------------------------------------------------------------------------ [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] There are test failures. Please refer to C:\AdminFolder\jackrabbit149\jackrabbit-core-1.4.9\target\surefire-reports for the individual test results. [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1 minute 43 seconds [INFO] Finished at: Mon Apr 06 16:41:39 BST 2009 [INFO] Final Memory: 16M/39M [INFO] ------------------------------------------------------------------------
        Hide
        Stefan Guggisberg added a comment -

        > Also , can someone please explain why these property files have null entry keys ? It seems to be a strange and non-semantic approach to achieve this configuration.

        it's not about null value keys, it's about empty string keys. namespace mappings are maintained in a HashMap (prefix->uri).

        please see the JCR 1.0 specification, 4.5 Namespaces. JCR has a notion of a default namespace (emtpy uri), which is
        referenced through the empty prefix ("").

        Show
        Stefan Guggisberg added a comment - > Also , can someone please explain why these property files have null entry keys ? It seems to be a strange and non-semantic approach to achieve this configuration. it's not about null value keys, it's about empty string keys. namespace mappings are maintained in a HashMap (prefix->uri). please see the JCR 1.0 specification, 4.5 Namespaces. JCR has a notion of a default namespace (emtpy uri), which is referenced through the empty prefix ("").
        Hide
        Paul Slattery added a comment -

        > please see the JCR 1.0 specification, 4.5 Namespaces. JCR has a notion of a default namespace (emtpy uri), which is
        referenced through the empty prefix ("").

        I still fail to see how this is in any way descriptive without tracing through the code.
        Could it not be given a key value default_ns or something else ?

        Show
        Paul Slattery added a comment - > please see the JCR 1.0 specification, 4.5 Namespaces. JCR has a notion of a default namespace (emtpy uri), which is referenced through the empty prefix (""). I still fail to see how this is in any way descriptive without tracing through the code. Could it not be given a key value default_ns or something else ?
        Hide
        Jukka Zitting added a comment -

        I don't think anyone is opposed to changing the key as it causes a clear problem on the IBM JVM.

        However, a change must pass all tests and be compatible with existing Jackrabbit installations before it can be accepted in Jackrabbit trunk.

        Show
        Jukka Zitting added a comment - I don't think anyone is opposed to changing the key as it causes a clear problem on the IBM JVM. However, a change must pass all tests and be compatible with existing Jackrabbit installations before it can be accepted in Jackrabbit trunk.
        Hide
        Chris Schmidt added a comment -

        Some additional information that may help here. This issue seems to only occur with IBM's 1.6 JDK. We used JackRabbit on AIX with JDK 1.5 and never encountered this issue. It wasn't until we tried upgrading to 1.6 that the issue occurred.

        IBM released an update to 1.6 a few months ago. I'll be testing the new service pack this week to see if it resolves the problem. If not I'll be working on a resolution since it is blocking us from deploying 1.6. Based on earlier comments, only org.apache.jackrabbit.core.query.lucene.FileBasedNamespaceMappings.java need to change in addition to NamespaceRegistryImpl.java?

        Show
        Chris Schmidt added a comment - Some additional information that may help here. This issue seems to only occur with IBM's 1.6 JDK. We used JackRabbit on AIX with JDK 1.5 and never encountered this issue. It wasn't until we tried upgrading to 1.6 that the issue occurred. IBM released an update to 1.6 a few months ago. I'll be testing the new service pack this week to see if it resolves the problem. If not I'll be working on a resolution since it is blocking us from deploying 1.6. Based on earlier comments, only org.apache.jackrabbit.core.query.lucene.FileBasedNamespaceMappings.java need to change in addition to NamespaceRegistryImpl.java?
        Hide
        Marcel Reutegger added a comment -

        AFAICS FileBasedNamespaceMappings does not use an empty key. It stores an index internal prefix to known namespace uris, where the internal prefixes are simply enumerated with an integer (even the empty namespace).

        Show
        Marcel Reutegger added a comment - AFAICS FileBasedNamespaceMappings does not use an empty key. It stores an index internal prefix to known namespace uris, where the internal prefixes are simply enumerated with an integer (even the empty namespace).
        Hide
        Stefan Guggisberg added a comment -

        in general a fix will have to make sure that the internal mapping of
        ns uri to integer is not affected, see my previous comment [1].

        ns uri's are internally assigned integer values. those integer values
        are persisted in place of the ns uri for space efficiency. any change
        in this assignment logic might break backwards compatibility.

        you might want to search for references/implementations of
        o.a.j.core.util.StringIndex.

        [1] https://issues.apache.org/jira/browse/JCR-888?focusedCommentId=12585041

        Show
        Stefan Guggisberg added a comment - in general a fix will have to make sure that the internal mapping of ns uri to integer is not affected, see my previous comment [1] . ns uri's are internally assigned integer values. those integer values are persisted in place of the ns uri for space efficiency. any change in this assignment logic might break backwards compatibility. you might want to search for references/implementations of o.a.j.core.util.StringIndex. [1] https://issues.apache.org/jira/browse/JCR-888?focusedCommentId=12585041
        Hide
        Chris Schmidt added a comment -

        I've had a chance to do a bit more work on this. There is one case that I'm not certain will keep the indexing value unfortunately. If a deployment of JackRabbit has already created the property files and it is loaded into the IBM 1.6 JRE, the default namespace will not be found. The only way I can think of fixing this case is if there is some mechanism to go into the filesystem and modify the property files prior to getting loaded in the Property file.

        I have a small patch that converts the empty string into a long-ish name when persisting to a property file. That shouldn't collide with existing URI/Prefixes, but I put the value into the restricted prefixes/uris just in case. The conversion is done for both the index values and the prefix/uri mapping. I've tested against a brand new deployment of JackRabbit under AIX and an existing deployment that originally exhibited the issue prior to the patch.

        I still haven't gotten the latest version of IBMs 1.6 JDK installed on AIX to test with. It is possible that this problem is fixed in SR4.

        Show
        Chris Schmidt added a comment - I've had a chance to do a bit more work on this. There is one case that I'm not certain will keep the indexing value unfortunately. If a deployment of JackRabbit has already created the property files and it is loaded into the IBM 1.6 JRE, the default namespace will not be found. The only way I can think of fixing this case is if there is some mechanism to go into the filesystem and modify the property files prior to getting loaded in the Property file. I have a small patch that converts the empty string into a long-ish name when persisting to a property file. That shouldn't collide with existing URI/Prefixes, but I put the value into the restricted prefixes/uris just in case. The conversion is done for both the index values and the prefix/uri mapping. I've tested against a brand new deployment of JackRabbit under AIX and an existing deployment that originally exhibited the issue prior to the patch. I still haven't gotten the latest version of IBMs 1.6 JDK installed on AIX to test with. It is possible that this problem is fixed in SR4.
        Hide
        Chris Schmidt added a comment -

        Patch that converts the default prefix/uri into a different value when persisting into a property file. Restores to the default value when loading from the same property file.

        Show
        Chris Schmidt added a comment - Patch that converts the default prefix/uri into a different value when persisting into a property file. Restores to the default value when loading from the same property file.
        Hide
        Kristin Obermyer added a comment -

        Would it be possible to include this patch in the next dot release (1.5.7)? Here at Oracle Primavera we have customers that use WebSphere 7 and are unable to use the workaround of switching to a different JRE. We analyzed the option of building the patch ourselves, and determined it would be best to receive an official patch from the Jackrabbit team. Thank you for your consideration.

        Show
        Kristin Obermyer added a comment - Would it be possible to include this patch in the next dot release (1.5.7)? Here at Oracle Primavera we have customers that use WebSphere 7 and are unable to use the workaround of switching to a different JRE. We analyzed the option of building the patch ourselves, and determined it would be best to receive an official patch from the Jackrabbit team. Thank you for your consideration.
        Hide
        Rob Owen added a comment -

        This problem was reported to IBM (PMR 52846 756 000) and they will have a fix.

        > From IBM Support Tuesday, June 23, 2009:
        > RE: PMR 52846 756 000 - problem with WAS 7.0.0.3 SDK and property files
        > JDK development team has worked on this problem and opened an APAR#IZ53551 to fix this defect.
        > JDK team has arrived at testfix. I've tested the fix and the fix has resolved the issue.
        > The fix will be published in JDK SR6.
        > IBM BPTSE Developer Services.

        Show
        Rob Owen added a comment - This problem was reported to IBM (PMR 52846 756 000) and they will have a fix. > From IBM Support Tuesday, June 23, 2009: > RE: PMR 52846 756 000 - problem with WAS 7.0.0.3 SDK and property files > JDK development team has worked on this problem and opened an APAR#IZ53551 to fix this defect. > JDK team has arrived at testfix. I've tested the fix and the fix has resolved the issue. > The fix will be published in JDK SR6. > IBM BPTSE Developer Services.
        Hide
        Ludo Cuypers added a comment -

        I installed IBM's JRE 1.6 SR5, but it returns the same result. What 's
        the easiest way to incorporate the Jackrabbit fix into my environment?
        Regards...

        Met vriendelijke groeten,
        Ludo
        -----------------------------------------------------------------
        Ludo Cuypers CIPAL - Cipalstraat 1, B2440 Geel
        e-mail : lcu@cipal.be
        Tel. : 014/57.62.11 - Tel.Direct :
        014/57.63.85
        -----------------------------------------------------------------

        ----Oorspronkelijk bericht----
        Van: Jukka Zitting (JIRA) jira@apache.org
        Verzonden: woensdag 8 juli 2009 12:48
        Aan: CUYPERS Ludo
        Onderwerp: [jira] Updated: (JCR-888) javax.jcr.NamespaceException: : is
        not a registered namespace uri

        [
        https://issues.apache.org/jira/browse/JCR-888?page=com.atlassian.jira.pl
        ugin.system.issuetabpanels:all-tabpanel ]

        Jukka Zitting updated JCR-888:
        ------------------------------

        Status: Patch Available (was: Reopened)

        NamespaceRegistryImpl.java.patch
        is created successfully the first time it is run. Subsequent attempts
        to login result in a javax.jcr.NamespaceException.
        registered namespace uri.
        org.apache.jackrabbit.core.NamespaceRegistryImpl.getPrefix(NamespaceRegi
        stryImpl.java:538)
        org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.checkNamespace(Node
        TypeRegistry.java:1292)
        org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.validateNodeTypeDef
        (NodeTypeRegistry.java:1415)
        org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.internalRegister(No
        deTypeRegistry.java:1221)
        org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.<init>(NodeTypeRegi
        stry.java:671)
        org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.create(NodeTypeRegi
        stry.java:118)
        org.apache.jackrabbit.core.RepositoryImpl.createNodeTypeRegistry(Reposit
        oryImpl.java:571)
        org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:262
        )
        org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:584
        )
        org.apache.jackrabbit.core.TransientRepository$2.getRepository(Transient
        Repository.java:245)
        org.apache.jackrabbit.core.TransientRepository.startRepository(Transient
        Repository.java:265)
        org.apache.jackrabbit.core.TransientRepository.login(TransientRepository
        .java:333)
        org.apache.jackrabbit.core.TransientRepository.login(TransientRepository
        .java:388)


        This message is automatically generated by JIRA.
        -
        You can reply to this email to add a comment to the issue online.

        Show
        Ludo Cuypers added a comment - I installed IBM's JRE 1.6 SR5, but it returns the same result. What 's the easiest way to incorporate the Jackrabbit fix into my environment? Regards... Met vriendelijke groeten, Ludo ----------------------------------------------------------------- Ludo Cuypers CIPAL - Cipalstraat 1, B2440 Geel e-mail : lcu@cipal.be Tel. : 014/57.62.11 - Tel.Direct : 014/57.63.85 ----------------------------------------------------------------- ---- Oorspronkelijk bericht ---- Van: Jukka Zitting (JIRA) jira@apache.org Verzonden: woensdag 8 juli 2009 12:48 Aan: CUYPERS Ludo Onderwerp: [jira] Updated: ( JCR-888 ) javax.jcr.NamespaceException: : is not a registered namespace uri [ https://issues.apache.org/jira/browse/JCR-888?page=com.atlassian.jira.pl ugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-888 : ------------------------------ Status: Patch Available (was: Reopened) NamespaceRegistryImpl.java.patch is created successfully the first time it is run. Subsequent attempts to login result in a javax.jcr.NamespaceException. registered namespace uri. org.apache.jackrabbit.core.NamespaceRegistryImpl.getPrefix(NamespaceRegi stryImpl.java:538) org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.checkNamespace(Node TypeRegistry.java:1292) org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.validateNodeTypeDef (NodeTypeRegistry.java:1415) org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.internalRegister(No deTypeRegistry.java:1221) org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.<init>(NodeTypeRegi stry.java:671) org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.create(NodeTypeRegi stry.java:118) org.apache.jackrabbit.core.RepositoryImpl.createNodeTypeRegistry(Reposit oryImpl.java:571) org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:262 ) org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:584 ) org.apache.jackrabbit.core.TransientRepository$2.getRepository(Transient Repository.java:245) org.apache.jackrabbit.core.TransientRepository.startRepository(Transient Repository.java:265) org.apache.jackrabbit.core.TransientRepository.login(TransientRepository .java:333) org.apache.jackrabbit.core.TransientRepository.login(TransientRepository .java:388) – This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
        Hide
        Ludo Cuypers added a comment -

        I recently installed IBM's Java 1.6 SR6, which solved the problem.
        Regards
        Ludo

        Show
        Ludo Cuypers added a comment - I recently installed IBM's Java 1.6 SR6, which solved the problem. Regards Ludo
        Hide
        Stefan Guggisberg added a comment -

        > I recently installed IBM's Java 1.6 SR6, which solved the problem.

        good to know, thanks for sharing this!

        cheers
        stefan

        Show
        Stefan Guggisberg added a comment - > I recently installed IBM's Java 1.6 SR6, which solved the problem. good to know, thanks for sharing this! cheers stefan
        Hide
        Ken W added a comment -

        Hi all,

        will this issue be included in any future jackrabbit releases? We encountered this issue installing Guvnor5 on IBM WAS 7.0.0.7. I believe this version of WAS is shipped with IBM JV 1.6 SR2 which has this problem. Really need this resolved because we can't switch to a different JRE.

        Regards,

        Ken

        Show
        Ken W added a comment - Hi all, will this issue be included in any future jackrabbit releases? We encountered this issue installing Guvnor5 on IBM WAS 7.0.0.7. I believe this version of WAS is shipped with IBM JV 1.6 SR2 which has this problem. Really need this resolved because we can't switch to a different JRE. Regards, Ken
        Hide
        Ludo Cuypers added a comment -

        Ik ben afwezig op 9 februari.
        Voor dringende zaken kan je terecht bij Linda Verachtert (LV@cipal.be) of Dirk Van Royen (DVR@cipal.be) .

        Show
        Ludo Cuypers added a comment - Ik ben afwezig op 9 februari. Voor dringende zaken kan je terecht bij Linda Verachtert (LV@cipal.be) of Dirk Van Royen (DVR@cipal.be) .
        Hide
        Jukka Zitting added a comment -

        Fixed in revision 950680 using a somewhat simpler approach that also takes care of backwards compatibility with earlier repository versions.

        Show
        Jukka Zitting added a comment - Fixed in revision 950680 using a somewhat simpler approach that also takes care of backwards compatibility with earlier repository versions.
        Hide
        Jukka Zitting added a comment -

        Merged to the 2.1 branch in revision 999905.

        Show
        Jukka Zitting added a comment - Merged to the 2.1 branch in revision 999905.

          People

          • Assignee:
            Jukka Zitting
            Reporter:
            Dave Erickson
          • Votes:
            10 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development