[jira] [Commented] (SLING-3114) DefaultContentImporter should guard against a closed InputStream on system view imports
[
https://issues.apache.org/jira/browse/SLING-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987619#comment-13987619
]
Oliver Lietz commented on SLING-3114:
-
https://github.com/oliverlietz/sling-tests/tree/master/org.apache.sling.tests/SLING-3114
DefaultContentImporter should guard against a closed InputStream on system
view imports
---
Key: SLING-3114
URL: https://issues.apache.org/jira/browse/SLING-3114
Project: Sling
Issue Type: Bug
Components: JCR
Affects Versions: JCR ContentLoader 2.1.6
Reporter: Alex Parvulescu
Assignee: Oliver Lietz
Priority: Minor
Fix For: JCR ContentLoader 2.1.8
For the special case of system view imports the null check [0] fails to take
into account the fact that the input stream is now closed (twice even [1],
[2]).
This means that if something happened and the import did not go throught
(hence the _null_ node), the code will continue and fail later (line 99) with
a cryptic message: _java.io.IOException: Stream Closed_ [3]
My proposal (no patch) is to add an else clause with a warn log and a return
statement.
[0]
http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/contentloader/src/main/java/org/apache/sling/jcr/contentloader/internal/DefaultContentImporter.java?view=markup#l77
[1]
http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/contentloader/src/main/java/org/apache/sling/jcr/contentloader/internal/DefaultContentImporter.java?view=markup#l201
[2]
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/AbstractSession.java?view=markup#l357
[3]
{noformat}
Caused by: java.io.IOException: Stream Closed
at java.io.FileInputStream.available(Native Method)
at java.io.BufferedInputStream.available(BufferedInputStream.java:399)
at
org.apache.sling.jcr.contentloader.internal.readers.XmlReader.parseInternal(XmlReader.java:205)
at
org.apache.sling.jcr.contentloader.internal.readers.XmlReader.parse(XmlReader.java:189)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SLING-3114) DefaultContentImporter should guard against a closed InputStream on system view imports
[
https://issues.apache.org/jira/browse/SLING-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987617#comment-13987617
]
Oliver Lietz commented on SLING-3114:
-
Fixed in r1591877 as described above (same behavior as in
{{org.apache.sling.jcr.contentloader.internal.Loader}}).
Other issues are tracked in SLING-3533, SLING-3534 and SLING-3535.
DefaultContentImporter should guard against a closed InputStream on system
view imports
---
Key: SLING-3114
URL: https://issues.apache.org/jira/browse/SLING-3114
Project: Sling
Issue Type: Bug
Components: JCR
Affects Versions: JCR ContentLoader 2.1.6
Reporter: Alex Parvulescu
Assignee: Oliver Lietz
Priority: Minor
Fix For: JCR ContentLoader 2.1.8
For the special case of system view imports the null check [0] fails to take
into account the fact that the input stream is now closed (twice even [1],
[2]).
This means that if something happened and the import did not go throught
(hence the _null_ node), the code will continue and fail later (line 99) with
a cryptic message: _java.io.IOException: Stream Closed_ [3]
My proposal (no patch) is to add an else clause with a warn log and a return
statement.
[0]
http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/contentloader/src/main/java/org/apache/sling/jcr/contentloader/internal/DefaultContentImporter.java?view=markup#l77
[1]
http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/contentloader/src/main/java/org/apache/sling/jcr/contentloader/internal/DefaultContentImporter.java?view=markup#l201
[2]
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/AbstractSession.java?view=markup#l357
[3]
{noformat}
Caused by: java.io.IOException: Stream Closed
at java.io.FileInputStream.available(Native Method)
at java.io.BufferedInputStream.available(BufferedInputStream.java:399)
at
org.apache.sling.jcr.contentloader.internal.readers.XmlReader.parseInternal(XmlReader.java:205)
at
org.apache.sling.jcr.contentloader.internal.readers.XmlReader.parse(XmlReader.java:189)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SLING-3114) DefaultContentImporter should guard against a closed InputStream on system view imports
[
https://issues.apache.org/jira/browse/SLING-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984419#comment-13984419
]
Oliver Lietz commented on SLING-3114:
-
[~alex.parvulescu], [~jukkaz] shouldn't we simply remove fallback to
{{DefaultContentCreator}} when extension {{.jcr.xml}} is used? (by moving
{{return}} to the end of the _system view imports_ block)
The name and error handling in _contentloader_ should be improved indeed - and
there are some more glitches which could be fixed.
DefaultContentImporter should guard against a closed InputStream on system
view imports
---
Key: SLING-3114
URL: https://issues.apache.org/jira/browse/SLING-3114
Project: Sling
Issue Type: Bug
Components: JCR
Affects Versions: JCR ContentLoader 2.1.6
Reporter: Alex Parvulescu
Assignee: Oliver Lietz
Priority: Minor
Fix For: JCR ContentLoader 2.1.8
For the special case of system view imports the null check [0] fails to take
into account the fact that the input stream is now closed (twice even [1],
[2]).
This means that if something happened and the import did not go throught
(hence the _null_ node), the code will continue and fail later (line 99) with
a cryptic message: _java.io.IOException: Stream Closed_ [3]
My proposal (no patch) is to add an else clause with a warn log and a return
statement.
[0]
http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/contentloader/src/main/java/org/apache/sling/jcr/contentloader/internal/DefaultContentImporter.java?view=markup#l77
[1]
http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/contentloader/src/main/java/org/apache/sling/jcr/contentloader/internal/DefaultContentImporter.java?view=markup#l201
[2]
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/AbstractSession.java?view=markup#l357
[3]
{noformat}
Caused by: java.io.IOException: Stream Closed
at java.io.FileInputStream.available(Native Method)
at java.io.BufferedInputStream.available(BufferedInputStream.java:399)
at
org.apache.sling.jcr.contentloader.internal.readers.XmlReader.parseInternal(XmlReader.java:205)
at
org.apache.sling.jcr.contentloader.internal.readers.XmlReader.parse(XmlReader.java:189)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SLING-3114) DefaultContentImporter should guard against a closed InputStream on system view imports
[
https://issues.apache.org/jira/browse/SLING-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777549#comment-13777549
]
Alex Parvulescu commented on SLING-3114:
fyi. [~jukkaz] found out that this is triggered in the cases where the file
size is above 256000 bytes [0]
More on the failed import case:
It can be that the node name parameter passed in is not the same as the node
from system view export file.
For example I can export /content/page, and the name I pass in is
'jcr:content', and I ask to be imported under '/content'. this will affect how
the system view import verifies if the import was successful:
'content'.hasChild('jcr:content').
So I'm guessing that the importer could be a bit smarter about this check, as
failing it means another import will happen with a fallback on the default
importer.
[0]
http://svn.apache.org/viewvc/sling/trunk/bundles/engine/src/main/java/org/apache/sling/engine/impl/parameters/ParameterSupport.java?view=markup#l187
DefaultContentImporter should guard against a closed InputStream on system
view imports
---
Key: SLING-3114
URL: https://issues.apache.org/jira/browse/SLING-3114
Project: Sling
Issue Type: Bug
Components: JCR
Affects Versions: JCR ContentLoader 2.1.6
Reporter: Alex Parvulescu
Priority: Minor
Fix For: JCR ContentLoader 2.1.8
For the special case of system view imports the null check [0] fails to take
into account the fact that the input stream is now closed (twice even [1],
[2]).
This means that if something happened and the import did not go throught
(hence the _null_ node), the code will continue and fail later (line 99) with
a cryptic message: _java.io.IOException: Stream Closed_ [3]
My proposal (no patch) is to add an else clause with a warn log and a return
statement.
[0]
http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/contentloader/src/main/java/org/apache/sling/jcr/contentloader/internal/DefaultContentImporter.java?view=markup#l77
[1]
http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/contentloader/src/main/java/org/apache/sling/jcr/contentloader/internal/DefaultContentImporter.java?view=markup#l201
[2]
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/AbstractSession.java?view=markup#l357
[3]
{noformat}
Caused by: java.io.IOException: Stream Closed
at java.io.FileInputStream.available(Native Method)
at java.io.BufferedInputStream.available(BufferedInputStream.java:399)
at
org.apache.sling.jcr.contentloader.internal.readers.XmlReader.parseInternal(XmlReader.java:205)
at
org.apache.sling.jcr.contentloader.internal.readers.XmlReader.parse(XmlReader.java:189)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
