"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]
