RE: [equinox-dev] Equinox/OSGi class loading and [de]serialization

["Neil Bartlett" <njbartlett@xxxxxxxxx>]

Mike,

Fragments are one possible solution, but probably not want you want,
because of other implications of using them.

The core of your problem is that you can't know at compile time (or bundle
construction time) which packages your main bundle needs to load. That
information is only known at runtime when you open one of your serialized
components.

The two traditional solutions to this are "DynamicImport-Package", or
"Buddy Loading". The latter is an Equinox-specific feature, whereas the
former is standard OSGi. I personally prefer the use of
DynamicImport-Package. To use it, add a line as follows to your main
bundle manifest:

  DynamicImport-Package: *

This will allow the bundle to resolve to any package exported by another
bundle that is currently resolved at runtime. (Note that you will need to
have some bundle exporting the package that your A, B and C classes can be
found in). However, the runtime will always use the statically bound
Import-Package and/or Require-Bundle declarations in preference to any
dynamic imports. Please read the description of DynamicImport-Package in
the spec for more information and caveats.

By the way, your question is probably more appropriate for the newsgroup
than this mailing list.

Regards,
Neil


> Sorry to reply to my own message here, but I just went back and reread
> the module layer section of the spec.  Are fragment bundles what I need
> here?  Is that the best solution?
>
>
>
> -Mike Furtak
>
>
>
>
>
> ________________________________
>
> From: equinox-dev-bounces@xxxxxxxxxxx
> [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Michael Furtak
> Sent: Thursday, March 01, 2007 11:23 AM
> To: Equinox development mailing list
> Subject: [equinox-dev] Equinox/OSGi class loading and [de]serialization
>
>
>
> Hello,
>
>
>
> I am looking for some advice regarding coping with the Equinox/OSGi
> bundle classloader architecture within the framework I am building.  The
> scenario is this:
>
>
>
> I have a bundle that defines an API for developing application
> components than can then be assembled into composite components.
> Component.java and CompositeComponent.java are defined within that API
> bundle.  Also defined within that API bundle is a class to help me
> serialize and deserialize [Composite]Components.
>
>
>
> Concrete component types are intended to be developed separately and
> contributed as plug-in bundles.  Therefore you could have a
> CompositeComponent consisting of 3 concrete components of differing
> types, A, B and C.
>
>
>
> The issue I am running into is the inability to deserialize a
> CompositeComponent containing types A, B, and C, because their concrete
> component class types are only defined within their respective bundles'
> classloaders.  i.e. when the CompositeComponent is instantiated,
> ClassNotFoundExceptions are thrown for types A, B, and C within the API
> bundle.
>
>
>
> Does anyone have a recommendation or strategy to cope with this?  I
> recognize that the classloader separation is part of the core of the
> architecture, but it seems to make [de]serialization a real challenge.
>
>
>
> Thanks,
>
> -Mike Furtak
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>