On 4/23/09 2:08 PM, Lloyd Chambers wrote:
> 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?
Hard to say.
> I'm not generating my own proxies, I'm using the standard
> java.lang.reflect.Proxy class.
As I pointed out below, java.lang.reflect.Proxy does sometimes present
some issues.
> 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.
Yes, you've made your opinion clear. On the other hand, some people feel
that making everything visible to everyone is a bug. I am not sure there
is much value in trying to take such a discussion to a conclusion.
Is this something you can boil down so I can take a look at it to try to
figure out what is happening?
-> richard
>
> 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
>>>>>> <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
>>>>
>>>>
>>>>
>
> Lloyd Chambers
> lloyd.chambers_at_sun.com <mailto:lloyd.chambers_at_sun.com>
> GlassFish Team
>
>
>