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: [email protected]
For additional commands, e-mail: [email protected]
--------
Christopher Armstrong
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
