You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2006/02/24 21:35:16 UTC
Installing bundles by reference
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.
Re: Typo in DefaultBundleArchive
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Oops, sorry about that. I checked in the fix into svn...good catch.
Thanks.
-> richard
Herko ter Horst wrote:
> Hi,
>
> I'm developing against the Felix SVN trunk, and after the latest
> update I ran into an issue where my app wouldn't start after running
> it for the first time. The cause seems to be a typo in
> DefaultBundleArchive that causes it to throw an Exception when the
> data storage directory already exists (instead of when it doesn't
> exist and can't be created either):
>
> Index:
> src/main/java/org/apache/felix/framework/cache/DefaultBundleArchive.java
> ===================================================================
> ---
> src/main/java/org/apache/felix/framework/cache/DefaultBundleArchive.java
> (revision 381114)
> +++
> src/main/java/org/apache/felix/framework/cache/DefaultBundleArchive.java
> (working copy)
> @@ -435,7 +435,7 @@
> // Get bundle data directory.
> File dataDir = new File(m_archiveRootDir, DATA_DIRECTORY);
> // Create the data directory if necessary.
> - if (DefaultBundleCache.getSecureAction().fileExists(dataDir))
> + if (!DefaultBundleCache.getSecureAction().fileExists(dataDir))
> {
> if (!DefaultBundleCache.getSecureAction().mkdir(dataDir))
> {
>
> Cheers,
>
> Herko ter Horst
>
Typo in DefaultBundleArchive
Posted by Herko ter Horst <he...@terhorst.net>.
Hi,
I'm developing against the Felix SVN trunk, and after the latest update
I ran into an issue where my app wouldn't start after running it for the
first time. The cause seems to be a typo in DefaultBundleArchive that
causes it to throw an Exception when the data storage directory already
exists (instead of when it doesn't exist and can't be created either):
Index:
src/main/java/org/apache/felix/framework/cache/DefaultBundleArchive.java
===================================================================
---
src/main/java/org/apache/felix/framework/cache/DefaultBundleArchive.java (revision
381114)
+++
src/main/java/org/apache/felix/framework/cache/DefaultBundleArchive.java (working
copy)
@@ -435,7 +435,7 @@
// Get bundle data directory.
File dataDir = new File(m_archiveRootDir, DATA_DIRECTORY);
// Create the data directory if necessary.
- if (DefaultBundleCache.getSecureAction().fileExists(dataDir))
+ if (!DefaultBundleCache.getSecureAction().fileExists(dataDir))
{
if (!DefaultBundleCache.getSecureAction().mkdir(dataDir))
{
Cheers,
Herko ter Horst
Re: Installing bundles by reference
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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.
>>
>
Re: Installing bundles by reference
Posted by Rob Walker <ro...@ascert.com>.
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.
>
--
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com