[SLING-1325] Bundle deploy fails utterly if any XML files contains an element named "type"

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: JCR Contentloader 2.0.4
• Fix Version/s: JCR Contentloader 2.0.6
• Assignee: Carsten Ziegeler
• Reporter: Stefan Seifert
• Created: 26/Jan/10 00:31
• Updated: 17/Feb/10 08:00
• Resolved: 26/Jan/10 09:04

Description

we encountered a strange bug working with the trunk version from sling: a simple change to an xml file resulted in white screens on every component request. the reason was that the "Sling-Initial-Content" part of the bundle could not be deployed, so all component definitions etc. stored as json files in the application could not be deployed.

source of the problem was this exception while deploying the bundle:

22.01.2010 12:24:06.493 *ERROR* [FelixPackageAdmin] org.apache.sling.jcr.contentloader.internal.Loader
Cannot load initial content for bundle de.eplus.ecsb.wlecc.wlecc : null javax.jcr.RepositoryException
        at org.apache.sling.jcr.contentloader.internal.Loader.createNode(Loader.java:491)
        at org.apache.sling.jcr.contentloader.internal.Loader.installFromPath(Loader.java:418)
        at org.apache.sling.jcr.contentloader.internal.Loader.installFromPath(Loader.java:391)
        at org.apache.sling.jcr.contentloader.internal.Loader.installContent(Loader.java:275)
        at org.apache.sling.jcr.contentloader.internal.Loader.registerBundleInternal(Loader.java:183)
        at org.apache.sling.jcr.contentloader.internal.Loader.registerBundle(Loader.java:122)
        at org.apache.sling.jcr.contentloader.internal.ContentLoaderService.bundleChanged(ContentLoaderService.java:133)
        at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:800)
        at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:728)
        at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:610)
        at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:3576)
        at org.apache.felix.framework.Felix.activateBundle(Felix.java:1690)
        at org.apache.felix.framework.Felix.startBundle(Felix.java:1622)
        at org.apache.felix.framework.Felix$RefreshHelper.restart(Felix.java:4280)
        at org.apache.felix.framework.Felix.refreshPackages(Felix.java:3415)
        at org.apache.felix.framework.PackageAdminImpl.run(PackageAdminImpl.java:329)
        at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
        at org.apache.sling.jcr.contentloader.internal.readers.XmlReader.parseInternal(XmlReader.java:225)
        at org.apache.sling.jcr.contentloader.internal.readers.XmlReader.parse(XmlReader.java:145)
        at org.apache.sling.jcr.contentloader.internal.Loader.createNode(Loader.java:485)
        ... 16 more

the exception contains not the content path that was affected by this error, but by debbuging with the sling sources we found out it was an xml file - that contained only application-specific data, and no jcr:content or anything. indeed we were able to reproduce the problem with a simple xml file like this:

<dummy>
  <type>This is a dummy string!</type>
</dummy>

if you rename the element "type" to "type2" or anything else the deployment is successful.

the reason is the class org.apache.sling.jcr.contentloader.internal.readers.XmlReader which seems to try to interpret our innocent XML file as something like jcr content and fails in the line 225.

perhaps a pre-check should be done if an xml file contains "jcr content" at all before the parsing process with XmlReader is started.