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