[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [equinox-dev] Equinox/OSGi class loading and [de]serialization

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




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.



-Mike Furtak