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]
