Richard,
- all of the involved modules all have "Import-Package" for
javax.management.
- the type in question is javax.management.ObjectName, which is part
of the JDK
How can javax.management.ObjectName, which is part of the JDK, and
imported, not be visible under these circumstances?
I'm not generating my own proxies, I'm using the standard
java.lang.reflect.Proxy class.
IMO, this is an OSGI bug, the JDK should work, end of story.
There should not be a "if you're using OSGi, you can't use JDK classes
without jumping through hoops".
And I don't know what hoop to jump through here.
Lloyd
On Apr 22, 2009, at 3:28 PM, Richard S. Hall wrote:
> 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
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>> Lloyd Chambers
>>> lloyd.chambers_at_sun.com
>>> GlassFish Team
>>>
>>>
>>>
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish Team