[
https://issues.apache.org/jira/browse/FELIX-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-1578.
------------------------------------
Resolution: Fixed
Fix Version/s: fileinstall-2.0.2
Assignee: Guillaume Nodet
Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M
fileinstall/src/main/java/org/apache/felix/fileinstall/internal/Artifact.java
M
fileinstall/src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java
M
fileinstall/src/main/java/org/apache/felix/fileinstall/internal/Scanner.java
M
fileinstall/src/main/java/org/apache/felix/fileinstall/internal/Util.java
Committed r824895
I've reused your idea but instead of storing the last modified date,
fileinstall now store the checksum which leads to more accurate results wrt to
updates.
Please reopen if needed.
> FileInstall issue when updating already installed bundles at startup time
> -------------------------------------------------------------------------
>
> Key: FELIX-1578
> URL: https://issues.apache.org/jira/browse/FELIX-1578
> Project: Felix
> Issue Type: Bug
> Components: File Install
> Reporter: Pierre De Rop
> Assignee: Guillaume Nodet
> Priority: Minor
> Fix For: fileinstall-2.0.2
>
> Attachments: FileInstall.patch.tgz
>
>
> I just got caught by a subtle issue regarding the way FileInstall updates
> already installed
> bundles at startup time. (I don't cleanup the cache when starting Felix).
> (the pb only occurs at startup time).
> When the fwk is started, FileInstall does a lookup on all already deployed
> bundles (see
> initializeCurrentManagedBundles method). This method relies on the
> Bundle.getLastModified() method
> in order to store in the Artifact the lastModified date of the bundle.
> -> The issue is that the Bundle.getLastModified() method returns the last
> time the bundle was
> installed, not the time of the bundle's location file when the bundle was
> installed.
> In our application server, we deploy our bundles using unix RPMs..
> But unfortunately, when RPMs are installed, the date of the bundles are not
> updated and are left to
> RPM build time.
> Let's consider a simple scenario:
> 1) Assuming that I have two rpms:
> MyBundle-jar-1.0 (build time: Sep 01)
> MyBundle-jar-1.1 (build time: Sep 05)
> 2) Now (Sep 10), I install MyBundle-jar-1.0 rpm (which build date is Sep 01)
> 3) Now, I startup my fwk and FileInstall loads the MyBundle.jar bundle.
> When installed, the Bundle.getLastModified() method returns Sep 10 (and
> not Sep 01 ...)
> 4) I stop my fwk.
> 4) Later on, at Sep 20, I decide to install the latest rpm (MyBundle-jar-1.1).
> So, in the load directory, I have now the MyBundle.jar, but with the rpm
> build
> date: Sep 05 ...
> 5) Now, I restart my fwk and here is the problem: FileInstall compares
> Bundle.lastModified() with
> the bundle file, which is older than the time when we previously installed
> the bundle:
>
> MyBundle.jar -> Sep 05
> Bundle.getLastModified() -> Sep 10
>
> and the bundle is not updated at startup. Notice that if I don't stop the
> fwk, then it
> works fine, and the bundle is updated. However, in development phase
> (while debugging),
> sometimes, we have to restart the fwk ...
>
> As a suggestion, attached to this issue a patch which seems to resolve the
> problem:
> Could you please take a look at it (it's attached to this issue).
> This patch is only a suggestion, and may be there are other simpler ways to
> solve the problem ... ?
> Here is what I have done in the patch:
> ->
> When installing/updating bundles, I store the date of the actual bundle into
> a file, in the
> FileInstall's BundleContext (using BundleContext.getDataFile()).
> in Util.java, I've added two new methods:
> ------------
> /**
> * Stores a lastModified date into a bundle context data file.
> * @param b The bundle whose lastModifed location file must be stored
> * @param date the lastModified date to be stored in bc
> * @param bc the FileInstall's bundle context where to store the
> lastModified date.
> */
> public static void setLastModified( Bundle b, long date, BundleContext bc
> )
> /**
> * Returns the lastModified date of a bundle.
> * @param b the bundle whose lastModifed location file must be returned
> * @param bc the FileInstall's bundle context.
> * @return the lastModified date of the bundle b
> */
> public static long getLastModified( Bundle b, BundleContext bc )
> in DirectoryWatcher.java:
> ------------------------
> 1) in the initializeCurrentManagedBundles() method, instead of storing
> Bundle.getLastModified() in the artifact,
> I load the bundle's lastModified date from the FileInstall's bundle context:
> svn diff ->
> - artifact.setLastModified(bundles[i].getLastModified());
> + artifact.setLastModified(Util.getLastModified(bundles[i],
> this.context));
> 2) when a new bundle is first installed, I store its lastModifed date into
> the FileInstall's bundle context file:
> svn diff ->
> bundle = context.installBundle(location, in);
> + Util.setLastModified( bundle, Util.getLastModified( path ),
> this.context );
> 3) when the bundle is updated, I also store its lastModifed date in the
> FileInstall's bundle context:
> svn diff ->
> bundle.update(in);
> + Util.setLastModified(bundle, Util.getLastModified( path ),
> this.context);
> 4) Finally, I also fixed the test which compares lastModifed dates without
> equality:
> - if (artifact.getLastModified() >
> Util.getLastModified(file))
> + if (artifact.getLastModified() >=
> Util.getLastModified(file))
> This last fix avoid updating the bundle each time the fwk is restarted ...
> WDYT ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
