cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: [RT] The impact of using OSGi
Date Mon, 25 Jul 2005 12:37:05 GMT
On Monday 25 July 2005 20:05, Upayavira wrote:
> Niclas Hedhman wrote:
> >>Building when you depend on java code in other bundles isn't that easy.
> >>For one, you may depend upon java classes which are in a jar embedded
> >>within another jar.
> >
> > 3. I think it is expected that classes that a Bundle depends on for its
> > on instantiation and execution, is distributed with it (or referenced in
> > the Manifest to a global resource (probably not recommended but
> > possible).
> I don't understand quite how this could work. After all, if one bundle
> depends upon another, if that bundle includes its dependency within it,
> hasn't that killed all benefit? Or must it just include the interface
> that its dependency bundle implements? Is that what you mean?

The classloading mechanism in OSGi is pretty complex, but essentially any 
bundle may export a particular Java class/interface (versioned).

So, if I have a Bundle that depends on AbcService, then my Bundle will not be 
able to "load" unless the AbcService interface is available, the notorious 
NoClassDefFoundError will result.
But, if I include all the classes that are required for my own compile, i.e. 
the interfaces, classes used in method arguments/return-types and exceptions, 
then my bundle can load without problems. And OSGi, will be able to cope with 
this situation when the implementing bundle gets loaded later.

It will also allow my bundle to either be loaded "standby", i.e. not started, 
or even started and be aware of the non-existence of the dependency and 
handle it in runtime, by listening in on Service events (or delegate it to a 
tracker to do it for you).

> > OSGi doesn't Import/Export classes, it only imports/exports packages. And
> > by using differnt <path> in Ant, you can make the distinction.
> See [1]. I would assume this is R4 syntax, although I can't be sure.

Ahhh... yes that must be R4. R3 doesn't have it. Ok. So we need better tools 
in the R4 world :o)

> >>So, the only solution we were able to come up with was to
> >>explode the dependency bundle's jar, only extracting the exported
> >>classes/interfaces.
> >
> > Not sure what you mean here.
> >
> > It seems to be a common pattern that a Bundle Jar has the "third-party
> > dependencies" in embedded Jars, while the classes "owned" by that Bundle
> > sits in the Jar root. This makes compiling easy and distribution harder,
> > since you probably want the exported classes from a Bundle to be inside
> > your bundle.
> Sorry, don't get why this makes distribution harder.

It means that I want to extract the API classes and re-distribute them in my 
own bundle (see above), which is not totally apparent what that is. And 
taking the entire Bundle is also a waste of payload, since it contains its 
dependencies as well in the embedded Jars.

> > I think there is room for a lot of improvement in the global OSGi
> > community about this. For instance, exported classes could (should?) be
> > published as Maven artifacts, and be referenced in the Manifest as
> > artifact: URLs (I have this working locally), and OSGi will resolve at
> > runtime which bundle actually exposes the exported classes.
> Doesn't it do this already? How does Maven add something here?

Yes, OSGi resolves correctly, but it is common that the Bundle classpath is 
set to jars internal to the Jar. By having URLs in the Bundle classpath, 
instead, will make it unnecessary to have the xstream-1.1.jar embedded, and 
rely on a Maven-repository-capable resolution/caching system to do this for 
you. Very sweet, provided you use such MRCRCS  :o)

> Yup. Move a few Cocoon devs over to Oscar and get the project going.
> Only problem is I haven't managed to get Cocoon to run with Oscar yet :-(

I have been busy with OSGi in another context, and not looked at the 
Cocoon-connection yet (and probably never will have enough time for that). 
The good side is that we are doing some progress on the tools front, so 
perhaps some of that work will improve life here as well, but that is still 
quite far off. :o(


View raw message