Ok so I did some more research on this and have come to the conclusion that (unfortunately) it cannot be done. Not without changing File Install at least.
File Install will always treat bundles that were installed by someone else as new when it encounters them in the deploy folder that it's scanning (felix.fileinstall.dir). When File Install encounters a bundle, it calculates the checksum for that bundle and attempts to load a previously stored checksum for that bundle from it's datafile space, using method BundleContext#getDataFile [http://www.osgi.org/javadoc/r4v42/org/osgi/framework/BundleContext.html #getDataFile(java.lang.String)]. If no checksum was found, or the checksums don't match, File Install treats the bundle as new. I tried to circumvent this problem by copying the logic for calculating the checksum to our own app, so we could calculate the checksums our selves when installing the bundles. There were two problems with this approach however: 1) The BundleContext for File Install is only available when it's STARTING, ACTIVE or STOPPING, but we want to prepare this before File Install starts. Without the BundleContext we can't call BundleContext.getDataFile to get a handle to the checksum file. 2) As soon as File Install starts it scans through the directory noting the existing checksums, even when (undocumented) property "felix.fileinstall.noInitialDelay" is set to false (default) so there is no time 'window of opportunity' for us to prepare these checksums. [http://svn.apache.org/viewvc/felix/trunk/fileinstall/src/main/java/org/ apache/felix/fileinstall/internal/DirectoryWatcher.java?view=markup] Possibly, we could solve this by changing FileInstall to accept a list of checksums for existing installed bundles so it could initialize them from there, but I'm not sure what would be the best way to communicate this list to File Install... probably the properties that are used now are not so suitable? -Stijn -----Original Message----- From: Stijn de Witt [mailto:[email protected]] Sent: maandag 7 juni 2010 17:30 To: [email protected] Subject: RE: File Install treats manually installed bundles as new when it starts Yes I see that you are right. It gets all the installed bundles from the bundle context and adds the ones that have a location matching it's watchdir to its currentManagedArtifacts map... Then later, when scanning the directory, it gets the bundle from the currentManagedArtifacts map and somehow compares the URL of the found bundle to the URL of the bundle in the watchdir... then it uses some magic I don't yet understand to determine whether it was modified. It returns false for bundles that were started from the Felix bundle cache, but unfortunately returns true for the bundles that we started by hand. In DirectoryWatcher#process: if (transformArtifact(artifact)) { modified.add(artifact); } transformArtifact returns true when we would like it to return false... Here is the magic I don't yet understand. In DirectoryWatcher#transformArtifact: else if (artifact.getListener() instanceof ArtifactUrlTransformer) { try { URL url = artifact.getJaredUrl(); URL transformed = ((ArtifactUrlTransformer) Artifact.getListener()).transform(url); if (transformed != null) { artifact.setTransformedUrl(transformed); return true; } } catch (Exception e) { log(Logger.LOG_WARNING, "Unable to transform artifact: " + artifact.getPath().getAbsolutePath(), e); } return false; } The call to transform() returns a URL that could be null... if it's not null the above method returns true, which in turn leads File Install to treat my bundle as modified. So that transform method must be really smart right? Here is what it's doing: In BundleTransformer.java: public URL transform(URL artifact) { return artifact; } What gives?? I'm lost. I will have to debug a lot more. Apparently at some earlier state, bundles installed and started from the bundle cache get a different transformer than the one our manually installed bundles get. One that returns null here, apparently. That, or the argument passed to transform() is already null... meaning artifact.getJaredUrl() would be null... Questions, questions. :) I will keep you posted and if my ramblings lead you to an idea that might be helpful, please don't hesitate to post it! :) -Stijn -----Original Message----- From: Richard S. Hall [mailto:[email protected]] Sent: maandag 7 juni 2010 16:35 To: [email protected] Subject: Re: File Install treats manually installed bundles as new when itstarts On 6/7/10 10:24, Stijn de Witt wrote: > Ok.. sorry to keep spamming you guys with my thoughts.. but: > > Thinking about this more I don't understand how it's possible that File > Install does not re-install all the bundles that were already in the > Felix bundlecache? Somewhere there must be a flaw in my thinking.... > > Any ideas? > I believe it stores info about the installed bundles into its private data area and then uses this as the baseline to determine if the bundles in the watched directory are different than what it last saw. -> richard > -Stijn > > > -----Original Message----- > From: Stijn de Witt [mailto:[email protected]] > Sent: maandag 7 juni 2010 16:15 > To: [email protected] > Subject: RE: File Install treats manually installed bundles as new when > it starts > > I have been reading the code for File Install and it looks like it keeps > track of a list of bundles that it is managing in > DirectoryWatcher.currentManagedArtifacts (package private). When it > encounters an artifact that is not already in that list, it assumes it > must be new and installs it. There seems no easy way to prevent this > behavior. > > I assumed that File Install would not attempt to install bundles that > were already running, but thinking more about it, it makes sense that it > has to keep track of the list of installed bundles itself. Being a > separate bundle it has no intimate knowledge of the Felix bundlecache... > > -Stijn > > > -----Original Message----- > From: Stijn de Witt [mailto:[email protected]] > Sent: maandag 7 juni 2010 11:30 > To: [email protected] > Subject: File Install treats manually installed bundles as new when it > starts > > Hi, > > > > As part of our upgrade process, we install our application's bundles > manually to prevent File Install from running during the upgrade. Once > the upgrade has completed, we start File Install. > > However, at that point it treats all bundles we already started manually > as 'new' and starts uninstalling the old ones and installing the 'new' > ones. So basically we see all our bundles being installed again. > > Does anyone maybe recognize this behavior? Can we prevent it from > happening? > > > > -Stijn > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
