Issues with installing bundles by reference

["Richard S. Hall" <he...@ungoverned.org>]

My modifications to Felix to support installing bundles by reference is 
reasonably simplistic. I just examine the URL string passed into 
BundleContext.installBundle() and then do the "right thing" based on its 
value. After implementing this approach it dawned on me that the OSGi 
mechanisms for installing and updating bundles are not parallel, they 
look like this:

    * BundleContext.installBundle(String location, InputStream is)
    * Bundle.update(InputStream is)

The downside of this lack of parallelism combined with my simple 
approach to reference URLs has an impact on how reference URLs can be 
updated. For example, if you want to install a bundle JAR file normally, 
but then later perform an update using a reference URL to a directory, 
then this would not be possible since update requires an input stream, 
but an input stream to a directory is not possible.

One approach for dealing with this is to actually use a URLStreamHandler 
for the reference protocol, then it would be possible to create a fake 
input stream object that could just return the original URL. Once the 
original URL is obtained, the rest of the process could work as it does now.

The downside of using a URLStreamHandler for updates is that it creates 
additional overhead and it creates a requirement on the URL Handlers 
service for it to work.

Of course, it would also be possible to just create a hybrid approach 
where if the URL Handlers service is activated it works and if it is not 
it works like the current simple implementation...the best [bloat] from 
both worlds. :-)

So, in short, what should we do. One or the other or both? Or just punt 
for now and wait until we have a real requirement?

-> richard

Re: Issues with installing bundles by reference

[Jeff McAffer <Je...@ca.ibm.com>]

Marcel Offermans <ma...@xs4all.nl> wrote on 02/24/2006 05:06:59 PM:
> The first scenario I thought of was when developing and deploying 
bundles, 
> being able to actually have bundles that reference a directory structure 

> would eliminate the need to (re)build bundle jars (and after triggering 
an 
> update in the framework, having that framework extract them again). This 

> scenario seems to be used in J2EE appservers too (for .war and .ear 
files).

Certainly this is an important one however it actually requires more than 
just install by reference.  For example, if you have some project 
(whatever) of source and you build it and want to install the result by 
reference as a bundle, the result has to be in the shape the bundle 
describes.  In particular, the Bundle-Classpath has to correctly identify 
the location of hte classes and resources.  Since the common case is to 
have a classpath of . then it means that the package dirs for the classes 
have to be directly in the parent of the MANIFEST.MF file or you have to 
implement a mechanism that allows you to map the classpath elements to 
build locations.  The latter is what we do in Eclipse to enable PDE's 
direct launching of plugins/projects.  This allows people to structure 
their output locations however they want and still just write code, save 
and launch.  No explicit compile or build steps needed.

> What other scenario's did you have in mind (if any)?

The other main usecase we have for by-reference is scaleablity.  If your 
system is actually installed on disk (as opposed to downloaded 
dynamically) then installing bundles by value duplicates the storage 
required.  Further, if you have the same disk-based bundle in multiple 
configurations/profiles, you would have to have one copy for each.  The 
approach we have taken is to allow for pools of bundles to be placed on 
disk and then define configurations that identify the plugins from that 
pool that should be run together.  No duplication, no copying, ...  Since 
some of the systems built on Eclipse are >1GB, this is an obvious win.

Jeff

Re: Issues with installing bundles by reference

[Marcel Offermans <ma...@xs4all.nl>]

On Friday 24 February 2006 22:31, Richard S. Hall wrote:

> My modifications to Felix to support installing bundles by reference is
> reasonably simplistic. [...]

> So, in short, what should we do. One or the other or both? Or just punt
> for now and wait until we have a real requirement?

The first scenario I thought of was when developing and deploying bundles, 
being able to actually have bundles that reference a directory structure 
would eliminate the need to (re)build bundle jars (and after triggering an 
update in the framework, having that framework extract them again). This 
scenario seems to be used in J2EE appservers too (for .war and .ear files).

What other scenario's did you have in mind (if any)?

Greetings, Marcel

Re: Issues with installing bundles by reference

[Rob Walker <ro...@ascert.com>]

> So, in short, what should we do. One or the other or both? Or just 
> punt for now and wait until we have a real requirement?

That'd be my vote. Send out the implementation as you have it for trial 
and review, and then tackle this area as and when you have a real 
use-case against which to determine a refined approach.

To be honest - I'd kind of expect problems updating JARs with this 
mechanism, and accept it as a price for the improvements gained with 
this route. We've had problems updating JARs that are being used in our 
live running App in other areas, and if this came with the same the 
benefits would still be worth it.

Regards

-- Rob


Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com

Re: Issues with installing bundles by reference

[Jeff McAffer <Je...@ca.ibm.com>]

FWIW, we use the reference: url handler approach in Equinox for pretty 
much the reasons you outlined.  I'm not sure if we fall back to string 
analysis if the URL mechanism is not available.

Jeff




"Richard S. Hall" <he...@ungoverned.org> 
02/24/2006 04:31 PM
Please respond to
felix-dev


To
felix-dev@incubator.apache.org
cc

Subject
Issues with installing bundles by reference






My modifications to Felix to support installing bundles by reference is 
reasonably simplistic. I just examine the URL string passed into 
BundleContext.installBundle() and then do the "right thing" based on its 
value. After implementing this approach it dawned on me that the OSGi 
mechanisms for installing and updating bundles are not parallel, they 
look like this:

    * BundleContext.installBundle(String location, InputStream is)
    * Bundle.update(InputStream is)

The downside of this lack of parallelism combined with my simple 
approach to reference URLs has an impact on how reference URLs can be 
updated. For example, if you want to install a bundle JAR file normally, 
but then later perform an update using a reference URL to a directory, 
then this would not be possible since update requires an input stream, 
but an input stream to a directory is not possible.

One approach for dealing with this is to actually use a URLStreamHandler 
for the reference protocol, then it would be possible to create a fake 
input stream object that could just return the original URL. Once the 
original URL is obtained, the rest of the process could work as it does 
now.

The downside of using a URLStreamHandler for updates is that it creates 
additional overhead and it creates a requirement on the URL Handlers 
service for it to work.

Of course, it would also be possible to just create a hybrid approach 
where if the URL Handlers service is activated it works and if it is not 
it works like the current simple implementation...the best [bloat] from 
both worlds. :-)

So, in short, what should we do. One or the other or both? Or just punt 
for now and wait until we have a real requirement?

-> richard