Thank you Richard for explaining. After I wrote that email, it did come
to my mind that what I was asking for is very very difficult to
implement (may be impossible without VM's support or even illegal as
you mentioned), because the class loader that loads api.Foo must be able
to load impl.FooImpl when impl.FooImpl is statically referenced from
api.Foo.
Thanks,
Sahoo
Richard S. Hall wrote:
Sahoo,
This is similar to how reflection also violates encapsulation. If you
don't want this behavior, you need to enable security and not grant
your bundles RuntimePermission("getClassLoader"). The OSGi framework
isn't trying to implement another security mechanism.
Even if you tried, it would be difficult for the OSGi framework to
know who is calling the loadClass() method of a bundle's class loader.
Further, I think it would violate the contract of ClassLoaders,
because you would want the same call to bundle class loader's
loadClass() to return different results depending on who was calling it.
The OSGi specification is trying to raise the level from abstraction
from ClassLoaders to bundles, so that most developers do not have to
deal with creating error-prone, custom class loaders. If you are using
OSGi technology and you are still messing with class loaders, then
this is considered an "advanced" or "expert" activity, much like
messing with reflection.
-> richard
Sahoo wrote:
Hi,
I am quite surprised to see that I am able to load classes belonging
to packages that are *not* exported. I am able to do so by using
getClassLoader() on an exported class. Here is my test case:
I have two bundles, viz: osgi-test2-foo and osgi-test2-bar. The
former one defines two packages, viz: sahoo.osgitest2.foo.api and
sahoo.osgitest2.foo.impl. The latter package is *not* exported. The
second bundle, osgi-test2-bar, imports the exported package
sahoo.osgitest2.foo.api. It also defines a class called
sahoo.osgitest2.bar.Bar, which is shown below. This class runs fine;
it is able to load FooImpl which is an un-exported class!
// Bar.java
package sahoo.osgitest2.bar; public class Bar implements
org.osgi.framework.BundleActivator {
public void start(org.osgi.framework.BundleContext context) throws
Exception { Class c =
sahoo.osgitest2.foo.api.Foo.class.getClassLoader().loadClass(
"sahoo.osgitest2.foo.impl.FooImpl"); }
public void stop(org.osgi.framework.BundleContext context) throws
Exception { }
}
I was hoping to see a ClassNotFoundException while trying to load
FooImpl from Bar. Any reason why OSGi allows this? Is there a way to
prevent such class loading?
Thanks, Sahoo
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]