You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Stefan Seifert (JIRA)" <ji...@apache.org> on 2010/01/26 01:32:34 UTC
[jira] Created: (SLING-1325) Bundle deploy fails utterly if any XML
files contains an element named
Bundle deploy fails utterly if any XML files contains an element named
----------------------------------------------------------------------
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
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.
[jira] Updated: (SLING-1325) Bundle deploy fails utterly if any XML
files contains an element named
Posted by "Stefan Seifert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Seifert updated SLING-1325:
----------------------------------
Attachment: slingtest-xmlfile.zip
i've added a small test project that allows to reproduce the problem with a "mvn install": slingtest-xmlfile.zip
> Bundle deploy fails utterly if any XML files contains an element named
> ----------------------------------------------------------------------
>
> 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: 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.
[jira] Updated: (SLING-1325) Bundle deploy fails utterly if any XML
files contains an element named "type"
Posted by "Stefan Seifert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Seifert updated SLING-1325:
----------------------------------
Summary: Bundle deploy fails utterly if any XML files contains an element named "type" (was: Bundle deploy fails utterly if any XML files contains an element named)
> 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: 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.
[jira] Commented: (SLING-1325) Bundle deploy fails utterly if any
XML files contains an element named "type"
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804941#action_12804941 ]
Carsten Ziegeler commented on SLING-1325:
-----------------------------------------
I've changed the code in revision 903115: it now throws an ioexception instread of the npe with a more specific exception message - containing the file name.
> 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.
[jira] Commented: (SLING-1325) Bundle deploy fails utterly if any
XML files contains an element named "type"
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804933#action_12804933 ]
Carsten Ziegeler commented on SLING-1325:
-----------------------------------------
By default, the contentloader tries to treat files with known file endings (xml, json) as files creating content. You can avoid this by specifying
see ignoreImportProviders directive for xml , see http://sling.apache.org/site/content-loading-jcrcontentloader.html
If your initial content contains xml files with jcr content and usual xml files, you have to split them into two different locations inside your bundle.
> 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.
[jira] Closed: (SLING-1325) Bundle deploy fails utterly if any XML
files contains an element named "type"
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Assigned: (SLING-1325) Bundle deploy fails utterly if any
XML files contains an element named "type"
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler reassigned SLING-1325:
---------------------------------------
Assignee: Carsten Ziegeler
> 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.
[jira] Updated: (SLING-1325) Bundle deploy fails utterly if any XML
files contains an element named "type"
Posted by "Stefan Seifert (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Resolved: (SLING-1325) Bundle deploy fails utterly if any
XML files contains an element named "type"
Posted by "Stefan Seifert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Seifert resolved SLING-1325.
-----------------------------------
Resolution: Fixed
error handling is much better now, and reconfiguring the ignored import providers solves the problem altogether - thanks!
> 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.