Richard,
I found that I was mistaken about module amx-config. It had no
reference to javax.management, so it had no Import-Package directive
for it.
That OSGi prevents access to standard JDK classes defies common sense
IMO, but that's the last I'll gripe about it.
...
The simplest solution I found was to add a dummy interface in the
module:
public interface ForceThisModuleToHaveAccesstoTheseTypes
{
public javax.management.ObjectName
forceInclusionOf_javax_management();
}
Adding this class causes Import-Package to include javax.management.
Lloyd
On Apr 23, 2009, at 12:07 PM, Richard S. Hall wrote:
> 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
>>>>>>> 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
>>
>>
>>
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish Team