You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Sahoo <Sa...@Sun.COM> on 2008/02/03 18:29:02 UTC
How can I prevent implementation class to be loadable by foreign
bundles?
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How can I prevent implementation class to be loadable by foreign
bundles?
Posted by Sahoo <sa...@sun.com>.
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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: How can I prevent implementation class to be loadable by foreign
bundles?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org