dev@glassfish.java.net

Re: broken Felix classloader?

From: Richard S. Hall <heavy_at_ungoverned.org>
Date: Wed, 22 Apr 2009 18:28:51 -0400

Lloyd,

One thing that dawned on me is that you have to make sure you create
your Proxy using a class loader that has visibility for all the types
you need. So double check which class loader you are using for that and
that it has access to the type in question.

Depending on your situation, you may have a more complicated case too.
For an example, this blog discusses a situation that Spring Source had:

     
http://www.osgi.org/blog/2008/08/classy-solutions-to-tricky-proxies.html

-> richard

On 4/22/09 11:43 AM, Richard S. Hall wrote:
> On 4/22/09 11:20 AM, Lloyd Chambers wrote:
>> So you're saying that if the bundle imports them, then they're
>> available and therefore OSGi has only bent the rules and not really
>> broken the JDK?
>
> No, I am just telling you how it is.
>
>> My bundle imports javax.management, and the Felix classloading still
>> fails.
>
> Understood, which is why I pointed out that it could be due to another
> issue if it is not the import.
>
> -> richard
>
>>
>> The class in question is javax.management.ObjectName. This is from
>> common/amx-ext-impl/target/amx-ext-impl.jar; the Import-Package is
>> apparently done by our build:
>>
>> Bundle-Description: implementation for amx-ext
>> Import-Package: com.sun.appserv.connectors.internal.api;version="3.0",
>> com.sun.enterprise.security.auth.realm;version="3.0",javax.management
>> ,javax.resource;version="1.6",org.glassfish.admin.amx.base;version="3
>> .0",org.glassfish.admin.amx.core;version="3.0",org.glassfish.admin.am
>> x.core.proxy;version="3.0",org.glassfish.admin.amx.impl.mbean;version
>> ="3.0",org.glassfish.admin.amx.impl.util;version="3.0",org.glassfish.
>> admin.amx.intf.config;version="3.0",org.glassfish.admin.amx.intf.conf
>> ig.grizzly;version="3.0",org.glassfish.admin.amx.util;version="3.0",o
>> rg.glassfish.admin.mbeanserver;version="3.0",org.glassfish.api.contai
>> ner;version="3.0",org.glassfish.api.deployment.archive;version="3.0",
>> org.glassfish.internal.api;version="3.0",org.glassfish.internal.data;
>> version="3.0",org.jvnet.hk2.annotations;version="0.3",org.jvnet.hk2.c
>> omponent;version="0.3",org.jvnet.hk2.config;version="0.3"
>>
>> Lloyd
>>
>> On Apr 22, 2009, at 7:36 AM, Richard S. Hall wrote:
>>
>>> On 4/22/09 12:48 AM, Bill Shannon wrote:
>>>> Richard S. Hall wrote:
>>>>> Lloyd,
>>>>>
>>>>> A bundle is only given implicit access to classes in java.*
>>>>> packages. All other packages must be imported. This includes
>>>>> javax.* packages. The reason is because javax packages are
>>>>> extensions. It is possible for them not to be there or for bundles
>>>>> to container newer versions. This would not be the case for java.*
>>>>> packages, which must be loaded by the boot class loader.
>>>>
>>>> That's not correct.
>>>>
>>>> Components of the JDK must always be available.
>>>
>>> In OSGi, classes outside of java.* are only available if the bundle
>>> imports them.
>>>
>>> -> richard
>>>
>>>>
>>>> There's a small list of packages for which applications are allowed
>>>> to provide newer versions.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> <mailto:dev-unsubscribe_at_glassfish.dev.java.net>
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>> <mailto:dev-help_at_glassfish.dev.java.net>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> <mailto:dev-unsubscribe_at_glassfish.dev.java.net>
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>> <mailto:dev-help_at_glassfish.dev.java.net>
>>>
>>
>> Lloyd Chambers
>> lloyd.chambers_at_sun.com <mailto:lloyd.chambers_at_sun.com>
>> GlassFish Team
>>
>>
>>