[ 
https://issues.apache.org/jira/browse/SLING-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Seifert updated SLING-1325:
----------------------------------

    Attachment: 100126_SLING-1325_patch.patch

as a first workaround i've created a patch that solves the NPE and let the 
bundle deploy pass successfully.


> Bundle deploy fails utterly if any XML files contains an element named "type"
> -----------------------------------------------------------------------------
>
>                 Key: SLING-1325
>                 URL: https://issues.apache.org/jira/browse/SLING-1325
>             Project: Sling
>          Issue Type: Bug
>    Affects Versions: JCR Contentloader 2.0.4
>            Reporter: Stefan Seifert
>             Fix For: JCR Contentloader 2.0.6
>
>         Attachments: 100126_SLING-1325_patch.patch, slingtest-xmlfile.zip
>
>
> 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:
> {noformat}
> 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
> {noformat}
> 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:
> {code:xml}
> <dummy>
>   <type>This is a dummy string!</type>
> </dummy>
> {code}
> 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.

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

Reply via email to