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
>>>>>>>> <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
>>>
>>>
>>>
>
> Lloyd Chambers
> lloyd.chambers_at_sun.com <mailto:lloyd.chambers_at_sun.com>
> GlassFish Team
>
>
>