felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Pauls <karlpa...@gmail.com>
Subject Re: Classloading across bundles and DynamicImport-package
Date Thu, 07 Aug 2008 22:33:28 GMT

Am 07.08.2008 um 18:09 schrieb "Stuart McCulloch" <stuart.mcculloch@jayway.net 

> 2008/8/7 Jackson, Bruce <brucej@qualcomm.com>
>> Its not exactly a legacy situation. The problem I have is one  
>> that's shared
>> with many object persistence frameworks that would naturally  
>> provide that
>> capability as a service in an OSGi environment.
>> In my case, the persistence model is based on the ability of any  
>> bundle to
>> declare an interface which is suitably annotated, and which the  
>> persistence
>> service will automatically construct suitable tables, views etc  
>> based on the
>> interface methods, arguments and annotations. An object factory in  
>> the
>> provider then generates a "real" object usable in the caller  
>> bundle, and
>> whose methods are interpreted by a dynamic proxy into calls to the
>> persistence layer.
>> The problem comes when you wish to extract information from the  
>> persistence
>> service. How do you recreate the stored object when the interface  
>> which was
>> used to create the dynamic proxy is not in the persistence layer's  
>> bundle?
> one possible solution that would work with all the current  
> frameworks is to
> use a service to get the interface class - based on something unique  
> in the
> persisted object like the interface name or serialization id
> client bundles would register service implementations, which return  
> any
> interface class(es) they know of that match the request. The  
> persistence
> bundle can then iterate over the available services until it finds  
> one that
> can supply the necessary runtime class (or it could use filters to  
> avoid
> iterating)
> alternatively... client bundles could register services to recreate  
> actual
> objects based on given data / schema.
> a lot of the classloading issues in OSGi can disappear when you use  
> services
> to delegate tasks to the bundles that have the required knowledge.  
> The hard
> part is deciding what to use services for, and what functionality to  
> push
> into which bundle - but you can often use standard OO techniques  
> like CRC
> cards to help brainstorm ideas
> imho, services are the best kept secret of OSGi...




> On 07/08/2008 15:31, "Richard S. Hall" <heavy@ungoverned.org> wrote:
>> Jackson, Bruce wrote:
>>> Does Felix support anything that carries out a similar function to  
>>> buddy
>> class loading in Equinox?
>>> I'm aware of the DynamicImport-Package, but that rather supposes  
>>> that the
>> bundle who declares this knows the bundles that it needs as  
>> "helpers" to
>> load classes.
>> Sorry, no, Felix does not support any such option. And you are right,
>> dynamic imports are probably not exactly what you want either.
>> Currently, it is possible that the spec will eventually define  
>> something
>> like this, but currently there is nothing. However, this should  
>> likely
>> only be used in legacy situations, is that your situation?
>> -> richard
> -- 
> Cheers, Stuart

View raw message