| Locked bundle on Windows prevents from Virgo IDE to resolve artefact [message #1062016] |
Wed, 05 June 2013 08:23  |
Eclipse User |
|
|
|
Hi all,
I have an issue with Windows and the Virgo IDE Tooling: some bundles locked by Windows prevent the Virgo IDE Tooling to resolve these bundles dependencies declared in the MANIFEST.MF.
To be more accurate, we have:
* a repository declared as an external repository
* in this repository, we have a libd file that declares a library. This library references some bundles that are located in the "usr" repository
For some reason, all the bundles declared in the library are locked by Windows. It looks like the fact they are locked prevent from the Virgo IDE Tooling resolving the import of the library in the MANIFEST.MF.
We don't know why these files are locked but unlocking them seems to fix the issue.
We also have from times to times some dependencies not found when starting the Virgo Runtime from the Virgo IDE Tooling and these bundle dependencies appears to be the locked files. We guess the two issues are related...
What we did not manage to find out is why the bundles declared in the libd are locked (may be a java.io stream that is not closed?)
I have added in attachment a simple test case with a README to reproduce the issue. But in the attachment you need to lock the bundle manually. We did not manage to get a simple example otherwise. And our Virgo infra is a bit more complicated (lots of legacy bundles) to be provided.
At last, having a bit debugging, I think the issue is in the "org.eclipse.virgo.util.io.FileSystemChecker.check()" of the project "org.eclipse.virgo.util.io".
In the attempt to fix our issue, we tried to use the latest code of the FileSystemChecker but we still have the issue...
And I am not sure but regarding the posts (http://www.bigsoft.co.uk/blog/index.php/2010/02/02/file-renameto-always-fails-on-windows && http://stackoverflow.com/questions/4179145/release-java-file-lock-in-windows), I was wondering whether the method "isUnlocked()" was not the root of the issue?
public boolean isUnlocked(File file) {
return !WINDOWS || file.renameTo(file);
}
Regarding the fact "file.renameTo(.)" returns false on a file locked by Windows, shouldn't be the code:
public boolean isUnlocked(File file) {
return WINDOWS || file.renameTo(file);
}
?
Note, we have patched our Virgo with a following modification of the check() method around line 287:
else if (size == monitorRecord.getSize() || isUnlocked(file)) {
// not changing anymore so if we can rename it we can announce it:
notifyListeners(this.key(file), monitorRecord.getEvent());
// do not monitor it anymore
this.monitorRecords.remove(keyFile);
}
But that's may be not the best patch. We will consider switching to the second bit of the code of this post?
Thanks in advance for any feedback.
------
Tested on:
- Windows7 (while no problem found on Linux)
- Virgo 3.5.0.RELEASE (and also with Virgo 3.6.2.RELEASE for the attachment sample)
- Virgo IDE Tooling 1.0.0 (and 1.0.1)
[Updated on: Wed, 05 June 2013 08:42] by Moderator |
|
|
|
|
Powered by
FUDForum. Page generated in 0.28832 seconds
Home
