Mailing-List: contact sling-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: sling-dev@incubator.apache.org
Message-ID: <1820828594.1228116884193.JavaMail.jira@brutus>
Date: Sun, 30 Nov 2008 23:34:44 -0800 (PST)
From: "Felix Meschberger (JIRA)" <jira@apache.org>
To: sling-dev@incubator.apache.org
Subject: [jira] Created: (SLING-745) Bundle installation fails if manifest
 is larger than 2K bytes
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Bundle installation fails if manifest is larger than 2K bytes
-------------------------------------------------------------

                 Key: SLING-745
                 URL: https://issues.apache.org/jira/browse/SLING-745
             Project: Sling
          Issue Type: Bug
          Components: JCR Install
    Affects Versions: JCR Install 2.0.4
            Reporter: Felix Meschberger
            Priority: Critical
             Fix For: JCR Install 2.0.4


Currently the BundleResourceProcessor marks the bundle input stream for 2048 bytes of read-head to read the MANIFEST.MF file. Unfortunately, this "limits" supprt for MANIFEST.MF files to 2048 bytes. We have one situation, where the actual MANIFEST.MF file is more than 64'000 bytes. Reading the MANIFEST.MF file succeeds but resetting the input stream fails.

I propose to modify the BundleResourceProcessor and the FileInstallableData as follows:

* BundleResourceProcessor.getMatchingBundle gets the InstallableData object and gets the InputStream directly from that one and also closes that "private" stream after reading the MANIFEST.MF file.
* FileInstallableData is modified to not open the InputStream before hand but to keep the JCR Property and open the stream on demand in the adaptTo method.
* BundleResourceProcessor.installOrUpdate is modified in the finally close to catch IOException on closing the input stream. In addition the null-check is not required because the data variable will never be null in the finally clause.

BTW: Opening the InputStream upfront in the FileInstallableData constructor may even leave this input stream open, should that stream not be retrieved to be closed !

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