Thanks Rob.
I look forward to hearing what kind of impact that has for your
application and what improvements or changes to it might be necessary.
Definitely keep me posted!
-> richard
Rob Walker wrote:
Firstly thanks to Richard - this is an important addition to Felix and
one which directly addresses the scaleability/duplication issue
mentioned by others, something that has been a nasty issue in our
application. It can be a tricky problem for Oscar/Felix based desktop
applications in a Windows/XP Enterprise environment where:
* Documents And Settings/user/.oscar - is often a network saved user
profile area, which can result in massive network transfers to
save the .oscar directories for an application ( > 100mb). For N
users this also multiplies the duplication issue * N since every
user ends up with a network saved copy of their .oscar
directories, usually all on the same domain controller server.
* Other areas on a user workstation are frequently locked down and
not writeable by a user, preventing or making difficult the use of
an alternative of C:\temp\.oscar for the cache directory
It also happens to tie in nicely with planned improvements to the
installing and launching of our Oscar based UI (including migration to
Felix).
We will certainly test this out and give feedback - although it may
take a few weeks to schedule time for this.
Regards
-- Rob
Richard S. Hall wrote:
Hey everyone,
I just committed an initial attempt to change the Felix bundle cache
implementation to support "reference" URLs. In addition to using a
standard URL to a JAR file, you can now also specify URLs like:
* reference:file:/foo/bundle.jar - this will use bundle.jar 'in
place' without copying it to the bundle cache; however, embedded
JARs and native libraries will still be copied to the cache.
* reference:file:/foo/bundle/ - this will use the directory as an
exploded bundle (i.e., a bundle JAR extracted into a directory)
and will not copy or extract anything to the cache.
I tested this and it appears to work for me. Some feedback would be
welcome.
One thing to keep in mind about using exploded bundles is that if
they contain native libraries you will run into linking problems if
you update them, since the native library will already be loaded by
another class loader.
Also, you will need to update the shell bundle in any existing
profiles to the new version, since some changes were required to the
install command.
-> richard
p.s. I will send another message to discuss some implementation
issues for which I would like some feedback.
