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]
