You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Carsten Ziegeler (JIRA)" <ji...@apache.org> on 2010/02/17 09:02:29 UTC
[jira] Closed: (SLING-1325) Bundle deploy fails utterly if any XML
files contains an element named "type"
[ https://issues.apache.org/jira/browse/SLING-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler closed SLING-1325.
-----------------------------------
> 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
> Assignee: Carsten Ziegeler
> 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.