river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Separating out RMIClassLoader dependencies
Date Thu, 15 Oct 2009 02:41:07 GMT
On Thu, Oct 15, 2009 at 12:42 AM, Gregg Wonderly <gregg@wonderly.org> wrote:

> Anyone have thoughts or questions?

For OSGi (maybe Netbeans as well) there might be additional
"problems", since "loading a class" is not a straight forward process
of calling a static provider. In OSGi, each "module" is wired up with
a "class space" but the same class name (difference version, different
provider, etc) may be in another "class space" in other modules. So,
to fulfill a contract where a static method gets called from
"anywhere" and I need to figure out which class to load is near
impossible (at least in a platform independent way) in OSGi, as you
will have to figure out which bundle (module) the caller reside in, in
an environment where multiple versions of the same class can exist.
(The reason this is near impossible is that the OSGi spec doesn't have
any Classloader API, from which the Bundle can be retrieved.)

"Class space" is a complex and powerful concept in OSGi, which
basically try to ensure that there are no class version clashes and
yet provide the class visibility needed.

OTOH, Paremus has shown that

 a) Locally available classes can be used,
 b) Remote classes be downloaded and wrapped in temporary bundles with
OSGi contracts honored.
 c) PreferredClassLoader is not needed.

So, perhaps your ambitions are too great and that you can/should
ignore OSGi's needs.


Cheers
-- 
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

Mime
View raw message