I guess in those situation you could always add "DynamicImport-Package:
*" or something, which is not very modular, but mimics the non-modular
behavior of the standard class path, which basically just gives you the
first thing it finds.
You are definitely correct that these situations create difficulties
when you are trying to use modules with explicit boundaries (similar
pains can be felt in marshalling/unmarshalling for persistence and
distribution). Typically, solutions in these areas assume they can see
everything, which is a very non-modular assumption...at best they can
see one version of everything, but are often wrong if there are multiple
versions.
We are in the midst of a transition to modularity, so we might start to
see some of these issues addressed at a lower level with Java SE/EE 7.
Unfortunately until then, we have to come up with workarounds.
-> richard
On 6/16/09 6:09 PM, Lloyd Chambers wrote:
> Richard,
>
> In thinking about this further, the situation seems worse that at
> first glance: suppose I have a method on the proxy discussed below:
>
> Object getSomething();
>
> And suppose that the actual return type can be any of 50 types, each
> from one of 50 different packages, all in the JDK (eg javax.management).
>
> One wouldn't know at *compile* time that that there are 50 latent
> runtime errors (NoClassDefFoundError).
>
> The product is tested with (say) 10 types; the problem is corrected
> for them. The customer is shipped a product that fails for the other
> 40 types.
>
> What prevents such an ugly scenario?
>
> What about future changes to the underlying code that returns still
> more types that the intermediate module knows nothing about leading to
> yet more runtime errors?
>
> Lloyd
>
> On Jun 16, 2009, at 2:58 PM, Lloyd Chambers wrote:
>
>> Richard,
>>
>> Thank you.
>>
>> That does seem to be it: the interface used (J2EEServer) resides in
>> the amx-j2ee module, which doesn't import javax.management. But it
>> does have a dependency on amx-core, which both imports and
>> exports javax.management (I checked the manifest).
>>
>> So even though the module implementing getSelf() uses
>> javax.management and the calling code does also, and the proxy code
>> does also, using that interface (J2EEServer) causes the problem.
>>
>> I guess that makes an explanation, but I still find it startling that
>> built-in JDK classes can be hidden this way and that dependencies
>> aren't really transitive.
>>
>> Lloyd
>>
>> On Jun 16, 2009, at 1:11 PM, Richard S. Hall wrote:
>>
>>> The last time this issue happened, it was because not all of the
>>> bundles involved import javax.management...
>>>
>>> Check the dev_at_glassfish mailing list archives for the thread "broken
>>> Felix classloader"...
>>>
>>> -> richard
>>>
>>> On 6/16/09 4:01 PM, Lloyd Chambers wrote:
>>>> I forgot to mention: the manifest includes javax.management. So
>>>> how can javax.management.ObjectName not be found?
>>>>
>>>> Import-Package: com.sun.enterprise.config.serverbeans;version="3.0",co
>>>> m.sun.enterprise.deployment;version="3.0",com.sun.enterprise.deployme
>>>> nt.io;version="3.0",com.sun.enterprise.deployment.util;version="3.0",
>>>> *javax.management*,javax.management.j2ee;version="1.1",javax.naming,jav
>>>> ax.rmi,org.glassfish.admin.amx.annotation;version="3.0",org.glassfish
>>>> .admin.amx.base;version="3.0",org.glassfish.admin.amx.config;version=
>>>> "3.0",org.glassfish.admin.amx.core;version="3.0",org.glassfish.admin.
>>>> amx.core.proxy;version="3.0",org.glassfish.admin.amx.impl.j2ee;versio
>>>> n="3.0",org.glassfish.admin.amx.impl.j2ee.loader;version="3.0",org.gl
>>>> assfish.admin.amx.impl.mbean;version="3.0",org.glassfish.admin.amx.im
>>>> pl.util;version="3.0",org.glassfish.admin.amx.intf.config;version="3.
>>>> 0",org.glassfish.admin.amx.j2ee;version="3.0",org.glassfish.admin.amx
>>>> .util;version="3.0",org.glassfish.admin.amx.util.jmx;version="3.0",or
>>>> g.glassfish.api.amx;version="3.0",org.glassfish.internal.data;version
>>>> ="3.0",org.jvnet.hk2.annotations;version="0.3",org.jvnet.hk2.componen
>>>> t;version="0.3"
>>>>
>>>>
>>>>
>>>> On Jun 16, 2009, at 12:51 PM, Lloyd Chambers wrote:
>>>>
>>>>> I've run into a problem like this before and I don't know why OSGI
>>>>> requires breaking the JDK. I forget the solution, but I'm stuck
>>>>> until I find one.
>>>>> ...
>>>>>
>>>>> Module amx-j2ee-impl has a dependency on module amx-core-impl, and
>>>>> calls getSelf(J2EEServer.class). Method getSelf() is in a
>>>>> superclass which is found in the amx-core-impl module. The
>>>>> generated proxy uses a handler defined in the amx-core module.
>>>>>
>>>>> The calling code looks like this:
>>>>>
>>>>> import javax.management.ObjectName; <=== imports the problem class
>>>>> ...
>>>>> J2EEServer selfProxy = getSelf(J2EEServer.class); <== call
>>>>> superclass method in another module
>>>>> ObjectName test = selfProxy.objectName(); <== ClassNotFoundException
>>>>>
>>>>> The proxy method objectName() returns a
>>>>> javax.management.ObjectName, a standard class in the JDK.
>>>>>
>>>>> Yet, I get a
>>>>> NoClassDefFoundError. This seems like a bug to me, and I don't know how to fix it.
>>>>>
>>>>>
>>>>> SEVERE: Caused by: java.lang.NoClassDefFoundError:
>>>>> javax/management/ObjectName
>>>>> Jun 16, 2009 12:38:16 PM
>>>>> SEVERE: at $Proxy107.objectName(Unknown Source)
>>>>> Jun 16, 2009 12:38:16 PM
>>>>> SEVERE: at
>>>>> org.glassfish.admin.amx.impl.j2ee.J2EEServerImpl.registerChildren(J2EEServerImpl.java:102)
>>>>> Jun 16, 2009 12:38:16 PM
>>>>> SEVERE: at
>>>>> org.glassfish.admin.amx.impl.j2ee.DASJ2EEServerImpl.registerChildren(DASJ2EEServerImpl.java:68)
>>>>> Jun 16, 2009 12:38:16 PM
>>>>> SEVERE: at
>>>>> org.glassfish.admin.amx.impl.mbean.AMXImplBase.postRegisterHook(AMXImplBase.java:1218)
>>>>> Jun 16, 2009 12:38:16 PM
>>>>> SEVERE: at
>>>>> org.glassfish.admin.amx.impl.mbean.MBeanImplBase.postRegister(MBeanImplBase.java:440)
>>>>> Jun 16, 2009 12:38:16 PM
>>>>> SEVERE: at
>>>>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.postRegisterInvoke(DefaultMBeanServerInterceptor.java:1035)
>>>>> Jun 16, 2009 12:38:16 PM
>>>>> SEVERE: ... 15 more
>>>>> Jun 16, 2009 12:38:16 PM
>>>>> SEVERE: Caused by: java.lang.ClassNotFoundException:
>>>>> javax.management.ObjectName
>>>>> Jun 16, 2009 12:38:16 PM
>>>>> SEVERE: at
>>>>> org.apache.felix.framework.searchpolicy.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:618)
>>>>> Jun 16, 2009 12:38:16 PM
>>>>> SEVERE: at
>>>>> org.apache.felix.framework.searchpolicy.ModuleImpl.access$100(ModuleImpl.java:59)
>>>>> Jun 16, 2009 12:38:16 PM
>>>>> SEVERE: at
>>>>> org.apache.felix.framework.searchpolicy.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1446)
>>>>> Jun 16, 2009 12:38:16 PM
>>>>> SEVERE: at java.lang.ClassLoader.loadClass(ClassLoader.java:254)
>>>>> Jun 16, 2009 12:38:16 PM
>>>>> SEVERE: at
>>>>> java.lang.ClassLoader.loadClassInternal(ClassLoader.java:402)
>>>>> Jun 16, 2009 12:38:16 PM
>>>>> SEVERE: ... 21 more
>>>>> Jun 16, 2009 12:38:16 PM
>>>>> org.glassfish.admin.amx.impl.loader.AMXStartupServiceNew
>>>>> _loadAMXMBeans
>>>>>
>>>>
>>>> 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
>
>
>