Richard,
Yes, it resolved the issue instantly.
Lloyd
On Apr 24, 2009, at 4:03 AM, Richard S. Hall wrote:
> And you are saying that this resolved the issue?
>
> -> richard
>
> On 4/23/09 6:43 PM, Lloyd Chambers wrote:
>>
>> 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
>>
>>
>>
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish Team