« Return to Thread: bundle imports
Re: bundle imports
by Richard S. Hall
::
Rate this Message:
This is not really a problem with OSGi per se, it is a problem of
modularity. OSGi enforces modularity. Existing persistence mechanisms
are not modular, since they assume they have access to all code.
The goal is to come up with an approach to support doing such things
that work well in OSGi and in the spirit of modularity. So, it is not a
problem, it is working as expected.
-> richard
On 7/2/09 8:41 PM, Christopher Armstrong wrote:
> Hi Mohnish
>
> Yes, this does seem to be a known problem with OSGi. I remember
> playing around with classloaders and the like the last time I
> attempted something like this with EclipseLink.
>
> There are various extensions to the standard supported by different
> runtimes to ease this problem, such as Require-Bundle, Eclipse Buddy
> mechanism, classloader switching, etc. It shows up prominently with
> ORM or persistence services that need to reflect on foreign classes.
>
> How do other people handle this scenario in Felix? Is this something
> that OSGi 4.2 was seeking to address?
>
> Cheers
> Chris
>
> On 03/07/2009, at 3:33 AM, mohn3310 wrote:
>
>>
>> Hello,
>>
>> This question grew out of the following thread on the castor-xml mailing
>> list:
>> http://www.nabble.com/castor-xml-writing-empty-file-td24175804.html
>>
>> I believe this is an osgi specific issue and wanted to follow up on
>> this to
>> further my understanding.
>>
>> The bundle using castor provides a generic "persistence" service...
>> hand it
>> an object and it will convert it to xml and marshall it to a file. To
>> make
>> it work successfully, I ended up having to add the package of the
>> object it
>> is handed, to the persistence bundle's imports list. But this isn't
>> viable... i.e. for every potential client of the bundle to keep
>> adding to
>> the imports list. The bundle shouldn't really know anything about its
>> clients.
>>
>> Why does it behave in such a way? Is this a limitation of the osgi
>> imports/exports model?
>>
>> Thanks,
>> Mohnish
>> --
>> View this message in context:
>> http://www.nabble.com/bundle-imports-tp24310965p24310965.html
>> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
> --------
> Christopher Armstrong
> carmstrong@...
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
modularity. OSGi enforces modularity. Existing persistence mechanisms
are not modular, since they assume they have access to all code.
The goal is to come up with an approach to support doing such things
that work well in OSGi and in the spirit of modularity. So, it is not a
problem, it is working as expected.
-> richard
On 7/2/09 8:41 PM, Christopher Armstrong wrote:
> Hi Mohnish
>
> Yes, this does seem to be a known problem with OSGi. I remember
> playing around with classloaders and the like the last time I
> attempted something like this with EclipseLink.
>
> There are various extensions to the standard supported by different
> runtimes to ease this problem, such as Require-Bundle, Eclipse Buddy
> mechanism, classloader switching, etc. It shows up prominently with
> ORM or persistence services that need to reflect on foreign classes.
>
> How do other people handle this scenario in Felix? Is this something
> that OSGi 4.2 was seeking to address?
>
> Cheers
> Chris
>
> On 03/07/2009, at 3:33 AM, mohn3310 wrote:
>
>>
>> Hello,
>>
>> This question grew out of the following thread on the castor-xml mailing
>> list:
>> http://www.nabble.com/castor-xml-writing-empty-file-td24175804.html
>>
>> I believe this is an osgi specific issue and wanted to follow up on
>> this to
>> further my understanding.
>>
>> The bundle using castor provides a generic "persistence" service...
>> hand it
>> an object and it will convert it to xml and marshall it to a file. To
>> make
>> it work successfully, I ended up having to add the package of the
>> object it
>> is handed, to the persistence bundle's imports list. But this isn't
>> viable... i.e. for every potential client of the bundle to keep
>> adding to
>> the imports list. The bundle shouldn't really know anything about its
>> clients.
>>
>> Why does it behave in such a way? Is this a limitation of the osgi
>> imports/exports model?
>>
>> Thanks,
>> Mohnish
>> --
>> View this message in context:
>> http://www.nabble.com/bundle-imports-tp24310965p24310965.html
>> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
> --------
> Christopher Armstrong
> carmstrong@...
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
« Return to Thread: bundle imports
| Free embeddable forum powered by Nabble | Forum Help |
