You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Pierre De Rop (JIRA)" <ji...@apache.org> on 2009/10/20 08:46:59 UTC
[jira] Created: (FELIX-1776) FileInstall starts already installed
bundles twice
FileInstall starts already installed bundles twice
--------------------------------------------------
Key: FELIX-1776
URL: https://issues.apache.org/jira/browse/FELIX-1776
Project: Felix
Issue Type: Bug
Components: File Install
Reporter: Pierre De Rop
This issue is described here: http://www.mail-archive.com/dev@felix.apache.org/msg13194.html
When the fwk is started without cleaning the cache, and when some bundles are already installed,
then fileinstall starts them twice.
Here is what I did in order to reproduce the problem
- I first did a simple "Test" bundle with the following activator:
public class Activator implements BundleActivator {
public void start(BundleContext ctx) throws Exception {
System.out.printlnp("start/version 1.0");
}
public void stop(BundleContext ctx) throws Exception {
System.out.printlnp("stop/version 1.0");
}
- in my "bundle" directory, I have:
org.apache.felix.shell.tui-1.5.0-SNAPSHOT.jar
org.apache.felix.shell-1.5.0-SNAPSHOT.jar
org.apache.felix.bundlerepository-1.5.0-SNAPSHOT.jar
org.apache.felix.fileinstall-2.0.3-SNAPSHOT.jar
org.apache.felix.configadmin-1.2.7-SNAPSHOT.jar
- in the directory which fileinstall polls for updated bundles, I only have my simple test.jar bundle:
ls ./deploy
test.jar
- Now, I start the fwk (from the trunk) with a cleaned cache:
rm -rf felix-cache
java -jar bin/felix.jar
{felix.fileinstall.poll (ms) = 2000, felix.fileinstall.dir = /home/nxuser/work/osgi/felix-trunk/main/deploy, felix.fileinstall.debug = -1, felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir = ./tmp, felix.fileinstall.filter = null}
->
-> Installed deploy/test.jar
start/version 1.0
Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
- I stop the fwk, and recompile my test bundle
- I restart the fwk, without cleaning the cache, and I have this
java -jar bin/felix.jar
Welcome to Felix
================
{felix.fileinstall.poll (ms) = 2000, felix.fileinstall.dir = /home/nxuser/work/osgi/felix-trunk/main/deploy, felix.fileinstall.debug = -1, felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir = ./tmp, felix.fileinstall.filter = null}
Updated /home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
start/version 1.1
Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
-> A bundle with the same symbolic name (test.dm) and version (1.0) is already installed. Updating this bundle instead.
stop/1.1
start/1.1
Installed deploy/test.jar
Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
I have attached a proposed patch to this issue, but please read it carefully because I am not sure about it.
Indeed, I suspect that the problem comes from the Scanner.run method, where the "storedChecksums" is removed from the map:
for (Iterator it = removed.iterator(); it.hasNext();)
{
File file = (File) it.next();
// Make sure we'll handle a file that has been deleted
files.addAll(removed);
// Remove no longer used checksums
lastChecksums.remove(file);
storedChecksums.remove(file); -> why doing so ? The getChecksum methods will returns 0
}
Because of the "storedChecksums.remove(file)" call, the scanner.getChecksum(File f) method always returns 0.
However, I'm not sure if this is really the bug, but because of this checksum removal, DIrectoryWatcher is no longer able to retrieve the correct checksum for tracked bundles.
So, I did the following safe patches in DirectoryWatcher.java and everything sounds to work fine now:
(in fact, I always call scanner.checksum(File) instead of scanner.getChecksum(File) ...)
svn diff src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java
@@ -297,7 +297,11 @@
// File has been modified
if (exists && artifact != null)
{
- artifact.setChecksum(scanner.getChecksum(file));
+ if (artifact.getChecksum() == scanner.checksum(file)) {
+ continue;
+ }
+
+ artifact.setChecksum(scanner.checksum(file));
// If there's no listener, this is because this artifact has been installed before
// fileinstall has been restarted. In this case, try to find a listener.
if (artifact.getListener() == null)
@@ -355,7 +359,7 @@
artifact.setJaredDirectory(jar);
artifact.setJaredUrl(jaredUrl);
artifact.setListener(listener);
- artifact.setChecksum(scanner.getChecksum(file));
+ artifact.setChecksum(scanner.checksum(file));
if (transformArtifact(artifact))
{
created.add(artifact);
Now, there is another issue I noticed.
It's not related to the current issue, and it's another one:
in the Utils.java, the getBundleKey(Bundle b) returns a string which is supposed to uniquely identify the bundle
(that is: Bundle-SymbolicName/Bundle Version).
However, it may happen that a bundle is updated with a new bundle version ... that's why I reworked this method,
in order to just simply return the path name of the bundle:
svn diff src/main/java/org/apache/felix/fileinstall/internal/Util.java
private static String getBundleKey(Bundle b)
{
- StringBuffer sb = new StringBuffer();
- sb.append(b.getSymbolicName()).append("_");
- String version = (String) b.getHeaders().get(Constants.BUNDLE_VERSION);
- sb.append(version != null ? version : Version.emptyVersion.toString());
- return sb.toString();
+ return getFile(b).getPath().replace(File.separator, "_");
}
+ private static File getFile(Bundle b)
+ {
+ try
+ {
+ String location = b.getLocation();
+ if (location.startsWith("file:"))
+ {
+ return new File(location.substring("file:".length()));
+ }
+ return new File(new URL(location).getFile());
+ }
+ catch (MalformedURLException e)
+ {
+ throw new RuntimeException("Could not get location from bundle "
+ + b.getLocation(), e);
+ }
+ }
Hope this helps;
/pierre
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1776) FileInstall starts already installed
bundles twice
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Guillaume Nodet resolved FELIX-1776.
------------------------------------
Assignee: Guillaume Nodet
Fix Version/s: fileinstall-2.0.10
Resolution: Fixed
Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M fileinstall/src/main/java/org/apache/felix/fileinstall/internal/Scanner.java
Committed r938115
I've fixed the relative directory issue, so i'm closing this one. Please reopen if needed.
> FileInstall starts already installed bundles twice
> --------------------------------------------------
>
> Key: FELIX-1776
> URL: https://issues.apache.org/jira/browse/FELIX-1776
> Project: Felix
> Issue Type: Bug
> Components: File Install
> Reporter: Pierre De Rop
> Assignee: Guillaume Nodet
> Fix For: fileinstall-2.0.10
>
> Attachments: fileinstall-patch.tgz
>
>
> This issue is described here: http://www.mail-archive.com/dev@felix.apache.org/msg13194.html
> When the fwk is started without cleaning the cache, and when some bundles are already installed,
> then fileinstall starts them twice.
> Here is what I did in order to reproduce the problem
> - I first did a simple "Test" bundle with the following activator:
> public class Activator implements BundleActivator {
> public void start(BundleContext ctx) throws Exception {
> System.out.printlnp("start/version 1.0");
> }
> public void stop(BundleContext ctx) throws Exception {
> System.out.printlnp("stop/version 1.0");
> }
> - in my "bundle" directory, I have:
> org.apache.felix.shell.tui-1.5.0-SNAPSHOT.jar
> org.apache.felix.shell-1.5.0-SNAPSHOT.jar
> org.apache.felix.bundlerepository-1.5.0-SNAPSHOT.jar
> org.apache.felix.fileinstall-2.0.3-SNAPSHOT.jar
> org.apache.felix.configadmin-1.2.7-SNAPSHOT.jar
> - in the directory which fileinstall polls for updated bundles, I only have my simple test.jar bundle:
> ls ./deploy
> test.jar
> - Now, I start the fwk (from the trunk) with a cleaned cache:
> rm -rf felix-cache
> java -jar bin/felix.jar
> {felix.fileinstall.poll (ms) = 2000, felix.fileinstall.dir = /home/nxuser/work/osgi/felix-trunk/main/deploy, felix.fileinstall.debug = -1, felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir = ./tmp, felix.fileinstall.filter = null}
> ->
> -> Installed deploy/test.jar
> start/version 1.0
> Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> - I stop the fwk, and recompile my test bundle
> - I restart the fwk, without cleaning the cache, and I have this
> java -jar bin/felix.jar
> Welcome to Felix
> ================
> {felix.fileinstall.poll (ms) = 2000, felix.fileinstall.dir = /home/nxuser/work/osgi/felix-trunk/main/deploy, felix.fileinstall.debug = -1, felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir = ./tmp, felix.fileinstall.filter = null}
> Updated /home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> start/version 1.1
> Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> -> A bundle with the same symbolic name (test.dm) and version (1.0) is already installed. Updating this bundle instead.
> stop/1.1
> start/1.1
> Installed deploy/test.jar
> Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> I have attached a proposed patch to this issue, but please read it carefully because I am not sure about it.
> Indeed, I suspect that the problem comes from the Scanner.run method, where the "storedChecksums" is removed from the map:
> for (Iterator it = removed.iterator(); it.hasNext();)
> {
> File file = (File) it.next();
> // Make sure we'll handle a file that has been deleted
> files.addAll(removed);
> // Remove no longer used checksums
> lastChecksums.remove(file);
> storedChecksums.remove(file); -> why doing so ? The getChecksum methods will returns 0
> }
> Because of the "storedChecksums.remove(file)" call, the scanner.getChecksum(File f) method always returns 0.
> However, I'm not sure if this is really the bug, but because of this checksum removal, DIrectoryWatcher is no longer able to retrieve the correct checksum for tracked bundles.
> So, I did the following safe patches in DirectoryWatcher.java and everything sounds to work fine now:
> (in fact, I always call scanner.checksum(File) instead of scanner.getChecksum(File) ...)
> svn diff src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java
> @@ -297,7 +297,11 @@
> // File has been modified
> if (exists && artifact != null)
> {
> - artifact.setChecksum(scanner.getChecksum(file));
> + if (artifact.getChecksum() == scanner.checksum(file)) {
> + continue;
> + }
> +
> + artifact.setChecksum(scanner.checksum(file));
> // If there's no listener, this is because this artifact has been installed before
> // fileinstall has been restarted. In this case, try to find a listener.
> if (artifact.getListener() == null)
> @@ -355,7 +359,7 @@
> artifact.setJaredDirectory(jar);
> artifact.setJaredUrl(jaredUrl);
> artifact.setListener(listener);
> - artifact.setChecksum(scanner.getChecksum(file));
> + artifact.setChecksum(scanner.checksum(file));
> if (transformArtifact(artifact))
> {
> created.add(artifact);
> Now, there is another issue I noticed.
> It's not related to the current issue, and it's another one:
> in the Utils.java, the getBundleKey(Bundle b) returns a string which is supposed to uniquely identify the bundle
> (that is: Bundle-SymbolicName/Bundle Version).
> However, it may happen that a bundle is updated with a new bundle version ... that's why I reworked this method,
> in order to just simply return the path name of the bundle:
> svn diff src/main/java/org/apache/felix/fileinstall/internal/Util.java
> private static String getBundleKey(Bundle b)
> {
> - StringBuffer sb = new StringBuffer();
> - sb.append(b.getSymbolicName()).append("_");
> - String version = (String) b.getHeaders().get(Constants.BUNDLE_VERSION);
> - sb.append(version != null ? version : Version.emptyVersion.toString());
> - return sb.toString();
> + return getFile(b).getPath().replace(File.separator, "_");
> }
> + private static File getFile(Bundle b)
> + {
> + try
> + {
> + String location = b.getLocation();
> + if (location.startsWith("file:"))
> + {
> + return new File(location.substring("file:".length()));
> + }
> + return new File(new URL(location).getFile());
> + }
> + catch (MalformedURLException e)
> + {
> + throw new RuntimeException("Could not get location from bundle "
> + + b.getLocation(), e);
> + }
> + }
> Hope this helps;
> /pierre
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1776) FileInstall starts already installed
bundles twice
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767740#action_12767740 ]
Guillaume Nodet commented on FELIX-1776:
----------------------------------------
I think the real problem is not in the call to Scanner.getChecksum().
The scanner forgets about checksums only for files that have been deleted from the file system, in which case the only thing to do is to uninstall the bundle (and we don't need the checksum anymore).
I'm not sure that your proposed patch for the getBundleKey is a good idea. The reason is that fileinstall is able to override already installed bundles with updated version copied to the watched folder, so we could end up with urls in very different formats (maven, war, etc...). I think using the bundle id should actually be sufficient.
I've just committed a fix for that. Could you please have a look and see if it works for you ?
Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M fileinstall/src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java
M fileinstall/src/main/java/org/apache/felix/fileinstall/internal/Util.java
Committed r826986
> FileInstall starts already installed bundles twice
> --------------------------------------------------
>
> Key: FELIX-1776
> URL: https://issues.apache.org/jira/browse/FELIX-1776
> Project: Felix
> Issue Type: Bug
> Components: File Install
> Reporter: Pierre De Rop
> Attachments: fileinstall-patch.tgz
>
>
> This issue is described here: http://www.mail-archive.com/dev@felix.apache.org/msg13194.html
> When the fwk is started without cleaning the cache, and when some bundles are already installed,
> then fileinstall starts them twice.
> Here is what I did in order to reproduce the problem
> - I first did a simple "Test" bundle with the following activator:
> public class Activator implements BundleActivator {
> public void start(BundleContext ctx) throws Exception {
> System.out.printlnp("start/version 1.0");
> }
> public void stop(BundleContext ctx) throws Exception {
> System.out.printlnp("stop/version 1.0");
> }
> - in my "bundle" directory, I have:
> org.apache.felix.shell.tui-1.5.0-SNAPSHOT.jar
> org.apache.felix.shell-1.5.0-SNAPSHOT.jar
> org.apache.felix.bundlerepository-1.5.0-SNAPSHOT.jar
> org.apache.felix.fileinstall-2.0.3-SNAPSHOT.jar
> org.apache.felix.configadmin-1.2.7-SNAPSHOT.jar
> - in the directory which fileinstall polls for updated bundles, I only have my simple test.jar bundle:
> ls ./deploy
> test.jar
> - Now, I start the fwk (from the trunk) with a cleaned cache:
> rm -rf felix-cache
> java -jar bin/felix.jar
> {felix.fileinstall.poll (ms) = 2000, felix.fileinstall.dir = /home/nxuser/work/osgi/felix-trunk/main/deploy, felix.fileinstall.debug = -1, felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir = ./tmp, felix.fileinstall.filter = null}
> ->
> -> Installed deploy/test.jar
> start/version 1.0
> Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> - I stop the fwk, and recompile my test bundle
> - I restart the fwk, without cleaning the cache, and I have this
> java -jar bin/felix.jar
> Welcome to Felix
> ================
> {felix.fileinstall.poll (ms) = 2000, felix.fileinstall.dir = /home/nxuser/work/osgi/felix-trunk/main/deploy, felix.fileinstall.debug = -1, felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir = ./tmp, felix.fileinstall.filter = null}
> Updated /home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> start/version 1.1
> Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> -> A bundle with the same symbolic name (test.dm) and version (1.0) is already installed. Updating this bundle instead.
> stop/1.1
> start/1.1
> Installed deploy/test.jar
> Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> I have attached a proposed patch to this issue, but please read it carefully because I am not sure about it.
> Indeed, I suspect that the problem comes from the Scanner.run method, where the "storedChecksums" is removed from the map:
> for (Iterator it = removed.iterator(); it.hasNext();)
> {
> File file = (File) it.next();
> // Make sure we'll handle a file that has been deleted
> files.addAll(removed);
> // Remove no longer used checksums
> lastChecksums.remove(file);
> storedChecksums.remove(file); -> why doing so ? The getChecksum methods will returns 0
> }
> Because of the "storedChecksums.remove(file)" call, the scanner.getChecksum(File f) method always returns 0.
> However, I'm not sure if this is really the bug, but because of this checksum removal, DIrectoryWatcher is no longer able to retrieve the correct checksum for tracked bundles.
> So, I did the following safe patches in DirectoryWatcher.java and everything sounds to work fine now:
> (in fact, I always call scanner.checksum(File) instead of scanner.getChecksum(File) ...)
> svn diff src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java
> @@ -297,7 +297,11 @@
> // File has been modified
> if (exists && artifact != null)
> {
> - artifact.setChecksum(scanner.getChecksum(file));
> + if (artifact.getChecksum() == scanner.checksum(file)) {
> + continue;
> + }
> +
> + artifact.setChecksum(scanner.checksum(file));
> // If there's no listener, this is because this artifact has been installed before
> // fileinstall has been restarted. In this case, try to find a listener.
> if (artifact.getListener() == null)
> @@ -355,7 +359,7 @@
> artifact.setJaredDirectory(jar);
> artifact.setJaredUrl(jaredUrl);
> artifact.setListener(listener);
> - artifact.setChecksum(scanner.getChecksum(file));
> + artifact.setChecksum(scanner.checksum(file));
> if (transformArtifact(artifact))
> {
> created.add(artifact);
> Now, there is another issue I noticed.
> It's not related to the current issue, and it's another one:
> in the Utils.java, the getBundleKey(Bundle b) returns a string which is supposed to uniquely identify the bundle
> (that is: Bundle-SymbolicName/Bundle Version).
> However, it may happen that a bundle is updated with a new bundle version ... that's why I reworked this method,
> in order to just simply return the path name of the bundle:
> svn diff src/main/java/org/apache/felix/fileinstall/internal/Util.java
> private static String getBundleKey(Bundle b)
> {
> - StringBuffer sb = new StringBuffer();
> - sb.append(b.getSymbolicName()).append("_");
> - String version = (String) b.getHeaders().get(Constants.BUNDLE_VERSION);
> - sb.append(version != null ? version : Version.emptyVersion.toString());
> - return sb.toString();
> + return getFile(b).getPath().replace(File.separator, "_");
> }
> + private static File getFile(Bundle b)
> + {
> + try
> + {
> + String location = b.getLocation();
> + if (location.startsWith("file:"))
> + {
> + return new File(location.substring("file:".length()));
> + }
> + return new File(new URL(location).getFile());
> + }
> + catch (MalformedURLException e)
> + {
> + throw new RuntimeException("Could not get location from bundle "
> + + b.getLocation(), e);
> + }
> + }
> Hope this helps;
> /pierre
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1776) FileInstall starts already installed
bundles twice
Posted by "Pierre De Rop (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pierre De Rop updated FELIX-1776:
---------------------------------
Attachment: fileinstall-patch.tgz
attached the proposed patch
> FileInstall starts already installed bundles twice
> --------------------------------------------------
>
> Key: FELIX-1776
> URL: https://issues.apache.org/jira/browse/FELIX-1776
> Project: Felix
> Issue Type: Bug
> Components: File Install
> Reporter: Pierre De Rop
> Attachments: fileinstall-patch.tgz
>
>
> This issue is described here: http://www.mail-archive.com/dev@felix.apache.org/msg13194.html
> When the fwk is started without cleaning the cache, and when some bundles are already installed,
> then fileinstall starts them twice.
> Here is what I did in order to reproduce the problem
> - I first did a simple "Test" bundle with the following activator:
> public class Activator implements BundleActivator {
> public void start(BundleContext ctx) throws Exception {
> System.out.printlnp("start/version 1.0");
> }
> public void stop(BundleContext ctx) throws Exception {
> System.out.printlnp("stop/version 1.0");
> }
> - in my "bundle" directory, I have:
> org.apache.felix.shell.tui-1.5.0-SNAPSHOT.jar
> org.apache.felix.shell-1.5.0-SNAPSHOT.jar
> org.apache.felix.bundlerepository-1.5.0-SNAPSHOT.jar
> org.apache.felix.fileinstall-2.0.3-SNAPSHOT.jar
> org.apache.felix.configadmin-1.2.7-SNAPSHOT.jar
> - in the directory which fileinstall polls for updated bundles, I only have my simple test.jar bundle:
> ls ./deploy
> test.jar
> - Now, I start the fwk (from the trunk) with a cleaned cache:
> rm -rf felix-cache
> java -jar bin/felix.jar
> {felix.fileinstall.poll (ms) = 2000, felix.fileinstall.dir = /home/nxuser/work/osgi/felix-trunk/main/deploy, felix.fileinstall.debug = -1, felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir = ./tmp, felix.fileinstall.filter = null}
> ->
> -> Installed deploy/test.jar
> start/version 1.0
> Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> - I stop the fwk, and recompile my test bundle
> - I restart the fwk, without cleaning the cache, and I have this
> java -jar bin/felix.jar
> Welcome to Felix
> ================
> {felix.fileinstall.poll (ms) = 2000, felix.fileinstall.dir = /home/nxuser/work/osgi/felix-trunk/main/deploy, felix.fileinstall.debug = -1, felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir = ./tmp, felix.fileinstall.filter = null}
> Updated /home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> start/version 1.1
> Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> -> A bundle with the same symbolic name (test.dm) and version (1.0) is already installed. Updating this bundle instead.
> stop/1.1
> start/1.1
> Installed deploy/test.jar
> Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> I have attached a proposed patch to this issue, but please read it carefully because I am not sure about it.
> Indeed, I suspect that the problem comes from the Scanner.run method, where the "storedChecksums" is removed from the map:
> for (Iterator it = removed.iterator(); it.hasNext();)
> {
> File file = (File) it.next();
> // Make sure we'll handle a file that has been deleted
> files.addAll(removed);
> // Remove no longer used checksums
> lastChecksums.remove(file);
> storedChecksums.remove(file); -> why doing so ? The getChecksum methods will returns 0
> }
> Because of the "storedChecksums.remove(file)" call, the scanner.getChecksum(File f) method always returns 0.
> However, I'm not sure if this is really the bug, but because of this checksum removal, DIrectoryWatcher is no longer able to retrieve the correct checksum for tracked bundles.
> So, I did the following safe patches in DirectoryWatcher.java and everything sounds to work fine now:
> (in fact, I always call scanner.checksum(File) instead of scanner.getChecksum(File) ...)
> svn diff src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java
> @@ -297,7 +297,11 @@
> // File has been modified
> if (exists && artifact != null)
> {
> - artifact.setChecksum(scanner.getChecksum(file));
> + if (artifact.getChecksum() == scanner.checksum(file)) {
> + continue;
> + }
> +
> + artifact.setChecksum(scanner.checksum(file));
> // If there's no listener, this is because this artifact has been installed before
> // fileinstall has been restarted. In this case, try to find a listener.
> if (artifact.getListener() == null)
> @@ -355,7 +359,7 @@
> artifact.setJaredDirectory(jar);
> artifact.setJaredUrl(jaredUrl);
> artifact.setListener(listener);
> - artifact.setChecksum(scanner.getChecksum(file));
> + artifact.setChecksum(scanner.checksum(file));
> if (transformArtifact(artifact))
> {
> created.add(artifact);
> Now, there is another issue I noticed.
> It's not related to the current issue, and it's another one:
> in the Utils.java, the getBundleKey(Bundle b) returns a string which is supposed to uniquely identify the bundle
> (that is: Bundle-SymbolicName/Bundle Version).
> However, it may happen that a bundle is updated with a new bundle version ... that's why I reworked this method,
> in order to just simply return the path name of the bundle:
> svn diff src/main/java/org/apache/felix/fileinstall/internal/Util.java
> private static String getBundleKey(Bundle b)
> {
> - StringBuffer sb = new StringBuffer();
> - sb.append(b.getSymbolicName()).append("_");
> - String version = (String) b.getHeaders().get(Constants.BUNDLE_VERSION);
> - sb.append(version != null ? version : Version.emptyVersion.toString());
> - return sb.toString();
> + return getFile(b).getPath().replace(File.separator, "_");
> }
> + private static File getFile(Bundle b)
> + {
> + try
> + {
> + String location = b.getLocation();
> + if (location.startsWith("file:"))
> + {
> + return new File(location.substring("file:".length()));
> + }
> + return new File(new URL(location).getFile());
> + }
> + catch (MalformedURLException e)
> + {
> + throw new RuntimeException("Could not get location from bundle "
> + + b.getLocation(), e);
> + }
> + }
> Hope this helps;
> /pierre
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1776) FileInstall starts already installed
bundles twice
Posted by "Pierre De Rop (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768464#action_12768464 ]
Pierre De Rop commented on FELIX-1776:
--------------------------------------
Hello Guillaume;
You are right, there's no problem with the Scanner.getChecksum() method.
Now, I did some further testing with your commit r826986 and I noticed the following:
The issue sounds to be resolved ... but only if I configure fileinstall like this:
- set the "felix.fileinstall.dir" option to an ABSOLUTE path (not a RELATIVE path)
- set the "felix.fileinstall.noInitialDelay=true"
1) working scenario:
everything works fine with the following scenario:
- "felix.fileinstall.dir=/home/pierre/felix-trunk/main/deploy"
- "felix.fileinstall.noInitialDelay=true"
- I have a test bundle inside my deploy dir
- I start the fwk -> the bundle is INSTALLED
- I stop the fwk and recompile my test bundle
- I restart the fwk -> the test bundle is UPDATED/STARTED
1) problematic scenario:
- "felix.fileinstall.dir=./deploy" (this is a relative path)
- I don't set the "felix.fileinstall.noInitialDelay" option, so the default value is "false"
- I have a test bundle inside my deploy dir
- I start the fwk -> the bundle is INSTALLED
- I stop the fwk and recompile my test bundle
- I restart the fwk -> the test bundle is UPDATED/STARTED/UPDATED/STARTED (but the test bundle should only be UPDATED/STARTED)
Now I think that, in the Scanner.scan() method, normalizing the scanned files seems to resolve the problem when the deploy dir
is configured to a RELATIVE path:
svn diff src/main/java/org/apache/felix/fileinstall/internal/Scanner.java
@@ -106,6 +106,7 @@
for (int i = 0; i < list.length; i++)
{
File file = list[i];
+ file = new File(file.toURI().normalize());
long lastChecksum = lastChecksums.get(file) != null ? ((Long) lastChecksums.get(file)).longValue() : 0;
... But:, when the "fileinstall.noInitialDelay" option is not set, and when I restart the fwk with a modified test bundle, the bundle is still started/updated/started.
In any case, now, I know that using an absolute path and noInitialDelay=true, then the issue does not arise anymore, so may be you could close this issue ?
What do you think ?
> FileInstall starts already installed bundles twice
> --------------------------------------------------
>
> Key: FELIX-1776
> URL: https://issues.apache.org/jira/browse/FELIX-1776
> Project: Felix
> Issue Type: Bug
> Components: File Install
> Reporter: Pierre De Rop
> Attachments: fileinstall-patch.tgz
>
>
> This issue is described here: http://www.mail-archive.com/dev@felix.apache.org/msg13194.html
> When the fwk is started without cleaning the cache, and when some bundles are already installed,
> then fileinstall starts them twice.
> Here is what I did in order to reproduce the problem
> - I first did a simple "Test" bundle with the following activator:
> public class Activator implements BundleActivator {
> public void start(BundleContext ctx) throws Exception {
> System.out.printlnp("start/version 1.0");
> }
> public void stop(BundleContext ctx) throws Exception {
> System.out.printlnp("stop/version 1.0");
> }
> - in my "bundle" directory, I have:
> org.apache.felix.shell.tui-1.5.0-SNAPSHOT.jar
> org.apache.felix.shell-1.5.0-SNAPSHOT.jar
> org.apache.felix.bundlerepository-1.5.0-SNAPSHOT.jar
> org.apache.felix.fileinstall-2.0.3-SNAPSHOT.jar
> org.apache.felix.configadmin-1.2.7-SNAPSHOT.jar
> - in the directory which fileinstall polls for updated bundles, I only have my simple test.jar bundle:
> ls ./deploy
> test.jar
> - Now, I start the fwk (from the trunk) with a cleaned cache:
> rm -rf felix-cache
> java -jar bin/felix.jar
> {felix.fileinstall.poll (ms) = 2000, felix.fileinstall.dir = /home/nxuser/work/osgi/felix-trunk/main/deploy, felix.fileinstall.debug = -1, felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir = ./tmp, felix.fileinstall.filter = null}
> ->
> -> Installed deploy/test.jar
> start/version 1.0
> Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> - I stop the fwk, and recompile my test bundle
> - I restart the fwk, without cleaning the cache, and I have this
> java -jar bin/felix.jar
> Welcome to Felix
> ================
> {felix.fileinstall.poll (ms) = 2000, felix.fileinstall.dir = /home/nxuser/work/osgi/felix-trunk/main/deploy, felix.fileinstall.debug = -1, felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir = ./tmp, felix.fileinstall.filter = null}
> Updated /home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> start/version 1.1
> Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> -> A bundle with the same symbolic name (test.dm) and version (1.0) is already installed. Updating this bundle instead.
> stop/1.1
> start/1.1
> Installed deploy/test.jar
> Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> I have attached a proposed patch to this issue, but please read it carefully because I am not sure about it.
> Indeed, I suspect that the problem comes from the Scanner.run method, where the "storedChecksums" is removed from the map:
> for (Iterator it = removed.iterator(); it.hasNext();)
> {
> File file = (File) it.next();
> // Make sure we'll handle a file that has been deleted
> files.addAll(removed);
> // Remove no longer used checksums
> lastChecksums.remove(file);
> storedChecksums.remove(file); -> why doing so ? The getChecksum methods will returns 0
> }
> Because of the "storedChecksums.remove(file)" call, the scanner.getChecksum(File f) method always returns 0.
> However, I'm not sure if this is really the bug, but because of this checksum removal, DIrectoryWatcher is no longer able to retrieve the correct checksum for tracked bundles.
> So, I did the following safe patches in DirectoryWatcher.java and everything sounds to work fine now:
> (in fact, I always call scanner.checksum(File) instead of scanner.getChecksum(File) ...)
> svn diff src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java
> @@ -297,7 +297,11 @@
> // File has been modified
> if (exists && artifact != null)
> {
> - artifact.setChecksum(scanner.getChecksum(file));
> + if (artifact.getChecksum() == scanner.checksum(file)) {
> + continue;
> + }
> +
> + artifact.setChecksum(scanner.checksum(file));
> // If there's no listener, this is because this artifact has been installed before
> // fileinstall has been restarted. In this case, try to find a listener.
> if (artifact.getListener() == null)
> @@ -355,7 +359,7 @@
> artifact.setJaredDirectory(jar);
> artifact.setJaredUrl(jaredUrl);
> artifact.setListener(listener);
> - artifact.setChecksum(scanner.getChecksum(file));
> + artifact.setChecksum(scanner.checksum(file));
> if (transformArtifact(artifact))
> {
> created.add(artifact);
> Now, there is another issue I noticed.
> It's not related to the current issue, and it's another one:
> in the Utils.java, the getBundleKey(Bundle b) returns a string which is supposed to uniquely identify the bundle
> (that is: Bundle-SymbolicName/Bundle Version).
> However, it may happen that a bundle is updated with a new bundle version ... that's why I reworked this method,
> in order to just simply return the path name of the bundle:
> svn diff src/main/java/org/apache/felix/fileinstall/internal/Util.java
> private static String getBundleKey(Bundle b)
> {
> - StringBuffer sb = new StringBuffer();
> - sb.append(b.getSymbolicName()).append("_");
> - String version = (String) b.getHeaders().get(Constants.BUNDLE_VERSION);
> - sb.append(version != null ? version : Version.emptyVersion.toString());
> - return sb.toString();
> + return getFile(b).getPath().replace(File.separator, "_");
> }
> + private static File getFile(Bundle b)
> + {
> + try
> + {
> + String location = b.getLocation();
> + if (location.startsWith("file:"))
> + {
> + return new File(location.substring("file:".length()));
> + }
> + return new File(new URL(location).getFile());
> + }
> + catch (MalformedURLException e)
> + {
> + throw new RuntimeException("Could not get location from bundle "
> + + b.getLocation(), e);
> + }
> + }
> Hope this helps;
> /pierre
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.