This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
If I have a class Installer, which is a subclass of ModuleInstall, and call ModuleInfo.owns(Installer.class) on the ModuleInfo object of the Module the Installer class belongs to, I get: true, if running the NetBeans Platform Application "normally" from the IDE false, if running as JNLP Application I debugged it and found that the ModuleInfo object is an instance of FixedModule and its superclass Module defines the owns method like this: public boolean owns(Class clazz) { ClassLoader cl = clazz.getClassLoader(); if (cl instanceof Util.ModuleProvider) { return ((Util.ModuleProvider) cl).getModule() == this; } return false; } When running as a JNLP Application, Installer.class.getClassLoader() returns com.sun.jnlp.JNLPClassLoader, which probably doesn't implement Util.ModuleProvider? Note, while we are at it, it would be good to have a method, which returns the ModuleInfo for a class, so one doesn't have to iterate over all instances, eg. something like: public static ModuleInfo getModuleInfo(Class clazz) { ClassLoader cl = clazz.getClassLoader(); if (cl instanceof Util.ModuleProvider) { return ((Util.ModuleProvider) cl).getModule(); } return null; }
Right, ModuleInfo.owns was never intended to work in JNLP mode, or generally for modules present in the application classpath rather than loaded dynamically in their own class loaders. I will check if this can be fixed in a straightforward way. Probably it can be for classes in the main module JAR but not for classes in Class-Path extensions. ModuleInfo.forClass(Class) could be useful - please file separately as an RFE (keyword API) as this would be tracked independently.
Created attachment 76492 [details] Demo app
core-main #ff998e324d9a
Thanks for the fix. I will use part of that code as a work-around until we can update to a version, which contains that fix. I couldn't see where the stream returned by manifest.openStream() gets closed. Couldn't this become a memory leak?
The stream would get closed upon GC but you're right that this should be closed more forcefully. core-main #58c5ca53da21
Integrated into 'main-golden', will be available in build *200902031446* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/ff998e324d9a User: Jesse Glick <jglick@netbeans.org> Log: #157798: ModuleInfo.owns(Class) did not work in JNLP mode.
OK, thanks. Note that your last fix (stream closing; core-main #58c5ca53da21) did not make it into 'main-golden' (http://hg.netbeans.org/main/rev/ff998e324d9a). Was this on purpose?
I filed an enhancement issue for the ModuleInfo.forClass(Class) method: http://www.netbeans.org/issues/show_bug.cgi?id=157828
Changesets propagate first from core-main to main (pretty quickly, after a continuous build accepts them), then later into main-golden (after an official daily development build passes). Should be there in a day or so.
Integrated into 'main-golden', will be available in build *200902041526* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/58c5ca53da21 User: Jesse Glick <jglick@netbeans.org> Log: #157798 refinement: close InputStream.
I just tested the fix of this issue with NetBeans IDE 6.7 Beta and the demo app of this issue: The ModuleInfo.owns now works when running from inside NetBeans either as JNLP application or as "normal" application. But when the war-file (Build JNLP Application) is deployed to an application server (eg. jboss v4.2.2) ModuleInfo.owns always returns true! (see attachment) Other tests showed that in a similar case Class.getProtectionDomain().getCodeSource().getLocation() doesn't return something that matches: file:.+\\.jar but a String, which starts with "http" and does NOT end with ".jar". Without further debugging I guess that the last line of org.netbeans.Module.owns comes into action in this case: return true; // not sure...
Created attachment 81760 [details] Bug screenshot
Confirmed with Glassfish 2.1. core-main #03cebc7a3dc4
Integrated into 'main-golden', will be available in build *200905141401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/03cebc7a3dc4 User: Jesse Glick <jglick@netbeans.org> Log: #157798 cont'd: original fix did not work when deployed as WAR.
My first tests showed that this generally works, thanks. But couldn't this become a performance issue because of the remote URL (http)? If I understand that code correctly, it will download the jar again for each call to ModuleInfo.owns. But since it is the jar of a class, which is already locally available, the jar should be locally available, too. Is there an API, which could be used in this fix, which accesses the local jar instead of the remote one? I could imagine, that this really could become an issue, when ModuleInfo.owns is called in a loop to get the one, which returns true (since there is no ModuleInfo.forClass(Class) method yet; see http://www.netbeans.org/issues/show_bug.cgi?id=157828 ).
JDK 6 javaws should automatically translate suitable http URLs to locally cached equivalent when opening them. That said, opening and parsing MANIFEST.MF of hundreds of modules even from a local JAR could be slow, so if ModuleInfo.owns turns out to be called repeatedly, a separate RFE could ask for it to keep a weak cache CodeSource -> codeName.