Yes, we have a 'management agent', our own code, which installs the bundles before upgrade. Still it doesn't seem like such a specific scenario to want to inform File Install of already running bundles before starting it.
The forking is probably a good idea. We will have to think about it some more. Thanks for discussing this with me. HTH, -Stijn -----Original Message----- From: Richard S. Hall [mailto:[email protected]] Sent: woensdag 9 juni 2010 17:31 To: [email protected] Subject: Re: File Install treats manually installed bundles as new when itstarts To me, this seems like the heart of the issue. Effectively, File Install is a simple management agent for the bundles it manages in its watched directory. You are trying to mix in another management agent during the update process, which makes your life more difficult...the OSGi vision of management agents doesn't work so well with overlapping management agents. Rather than trying to make File Install somehow integrate other management agents, which will likely be ugly and very scenario specific, it would likely make more sense to think about how to get File Install to notify you when its done. Even this may not make so much sense, but I think that is a better approach. Otherwise, you might be better off taking File Install as your base and creating your own custom version of a management agent with it (i.e., fork it for your specific needs). Of course, we're always open for brilliant suggestions! :-) -> richard On 6/9/10 10:47, Stijn de Witt wrote: > "Why don't you want to just let File Install install them in the first > place?" > > Good question. Basically two reasons, one small and one big. > > We have an upgrade process (legacy, pre-OSGI, for bundles we do this on > the fly) where we run the new version of the software against the old > database and then update the database to match the current state of the > software. (Field type changed, change column type in DB etc). We store > the software version in the database and if we detect that it does not > match that of the installed software we put the application in UPGRADE > mode and enter the upgrade process. It is in this process that we don't > want File Install running. > > Small reason: It doesn't feel right to have File Install monitor for > updated bundles during the upgrade process. We need some stability in > that phase. > > Big reason: File Install is asynchronous so we don't know when it's done > starting bundles. In contrast our manual routine just scans the bundle > deploy folder once, and loops through them installing and starting them > and then we know for sure they are all running and can start the > upgrade. > > Our problem occurs after the upgrade has completed successfully. We put > the application in NORMAL mode and enable File Install again, but then > the first thing it does is uninstall all our manually installed bundles > and install them again. > > Here is a flow diagram of the startup sequence (hope it survives the > mail): > > Start > | > | > <upgrade needed?> > | | > [yes] [no] > | | > Clear bundle Start cached > cache bundles (runlevel = 1) > | | > Manually | > Start bundles | > | | > Upgrade | > | | > \------------/ > | > | > Start File Install (runlevel to 2) > > > -Stijn > > > > -----Original Message----- > From: Richard S. Hall [mailto:[email protected]] > Sent: woensdag 9 juni 2010 16:20 > To: [email protected] > Subject: Re: File Install treats manually installed bundles as new when > itstarts > > One question that hasn't been asked yet, why don't you want to just let > File Install install them in the first place? > > -> richard > > On 6/9/10 8:39, Stijn de Witt wrote: > >> 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] >> >> >> > --------------------------------------------------------------------- > 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]
