[
https://issues.apache.org/jira/browse/FELIX-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated FELIX-1310:
-------------------------------------
Description:
Under certain circumstances not yet exactly known to me a strange error may be
logged when the framework starts:
08.07.2009 16:16:32 *ERROR* webapp-CRX Launchpad Webapp: ERROR:
org.apache.felix.framework.cache.BundleCache:
Error creating archive. (java.io.FileNotFoundException:
....\felix\bundle85\version298.-1\revision.location
(The system cannot find the path specified))
I trace this to BundleArchive(Logger logger, Map configMap, File
archiveRootDir) constructor which does:
int revisionCount = 0;
while (true)
{
File revisionRootDir = new File(m_archiveRootDir,
REVISION_DIRECTORY + getRefreshCount() + "." + revisionCount);
if (!BundleCache.getSecureAction().fileExists(revisionRootDir))
{
break;
}
revisionCount++;
}
if (revisionCount > 1)
{
m_revisions = new BundleRevision[revisionCount - 1];
}
revise(getRevisionLocation(revisionCount - 1), null);
and given that there is no folder ....\felix\bundle85\version298.0 the loop
will immediately terminate with revisionCount=0 and hence call
getRevisionLocation with a revision number of "-1".
I assume the revisionCount=0 state should be guarded here .. But I do not
exactly know what the correct solution would be.
My assumption would be that the user tried to update Bundle 85 from 297 to 298
but the update was interrupted by a system termination, since the version297.0
still exists but the refresh count file has already been updated to 298 (so it
looks).
I am currently asking the user for more information and will ammend this issue
as soon as I have it.
We have observed the problem on an 1.6.0 framework instance. The BundleCache
initialization code, though, is still the same in trunk.
was:
Under certain circumstances not yet exactly known to me a strange error may be
logged when the framework starts:
08.07.2009 16:16:32 *ERROR* webapp-CRX Launchpad Webapp: ERROR:
org.apache.felix.framework.cache.BundleCache:
Error creating archive. (java.io.FileNotFoundException:
....\felix\bundle85\version298.-1\revision.location
(The system cannot find the path specified))
I trace this to BundleArchive(Logger logger, Map configMap, File
archiveRootDir) constructor which does:
int revisionCount = 0;
while (true)
{
File revisionRootDir = new File(m_archiveRootDir,
REVISION_DIRECTORY + getRefreshCount() + "." + revisionCount);
if (!BundleCache.getSecureAction().fileExists(revisionRootDir))
{
break;
}
revisionCount++;
}
if (revisionCount > 1)
{
m_revisions = new BundleRevision[revisionCount - 1];
}
revise(getRevisionLocation(revisionCount - 1), null);
and given that there is no folder ....\felix\bundle85\version298.0 the loop
will immediately terminate with revisionCount=0 and hence call
getRevisionLocation with a revision number of "-1".
I assume the revisionCount=0 state should be guarded here .. But I do not
exactly know what the correct solution would be.
My assumption would be that the user tried to update Bundle 85 from 297 to 298
but the update was interrupted by a system termination, since the version297.0
still exists but the refresh count file has already been updated to 298 (so it
looks).
I am currently asking the user for more information and will ammend this issue
as soon as I have it.
Affects Version/s: (was: felix-1.8.1)
(was: felix-2.0.0)
(was: felix-1.6.1)
(was: felix-1.8.0)
> BundleCache may fail to initialize
> ----------------------------------
>
> Key: FELIX-1310
> URL: https://issues.apache.org/jira/browse/FELIX-1310
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: felix-1.6.0
> Reporter: Felix Meschberger
>
> Under certain circumstances not yet exactly known to me a strange error may
> be logged when the framework starts:
> 08.07.2009 16:16:32 *ERROR* webapp-CRX Launchpad Webapp: ERROR:
> org.apache.felix.framework.cache.BundleCache:
> Error creating archive. (java.io.FileNotFoundException:
> ....\felix\bundle85\version298.-1\revision.location
> (The system cannot find the path specified))
> I trace this to BundleArchive(Logger logger, Map configMap, File
> archiveRootDir) constructor which does:
> int revisionCount = 0;
> while (true)
> {
> File revisionRootDir = new File(m_archiveRootDir,
> REVISION_DIRECTORY + getRefreshCount() + "." + revisionCount);
> if (!BundleCache.getSecureAction().fileExists(revisionRootDir))
> {
> break;
> }
> revisionCount++;
> }
> if (revisionCount > 1)
> {
> m_revisions = new BundleRevision[revisionCount - 1];
> }
> revise(getRevisionLocation(revisionCount - 1), null);
> and given that there is no folder ....\felix\bundle85\version298.0 the loop
> will immediately terminate with revisionCount=0 and hence call
> getRevisionLocation with a revision number of "-1".
> I assume the revisionCount=0 state should be guarded here .. But I do not
> exactly know what the correct solution would be.
> My assumption would be that the user tried to update Bundle 85 from 297 to
> 298 but the update was interrupted by a system termination, since the
> version297.0 still exists but the refresh count file has already been updated
> to 298 (so it looks).
> I am currently asking the user for more information and will ammend this
> issue as soon as I have it.
> We have observed the problem on an 1.6.0 framework instance. The BundleCache
> initialization code, though, is still the same in trunk.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
