Richard,
Sounds like "DynamicImport-Package: *" might be just right: a module
consisting almost or entirely of interfaces intended for use as
dynamic proxies, it essentially becomes a gateway through which
everything passes, yet can't possibly anticipate all the types that
might need to be visible.
Lloyd
On Jun 16, 2009, at 5:54 PM, Richard S. Hall wrote:
> 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
>>>>> 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