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.

Bug 127268

Summary: URLMapper.findFileObject(url) returns null
Product: platform Reporter: Jiri Skrivanek <jskrivanek>
Component: Module SystemAssignee: Jesse Glick <jglick>
Status: VERIFIED DUPLICATE    
Severity: blocker CC: jtulach, mmirilovic, pnejedly, rmatous
Priority: P2 Keywords: REGRESSION
Version: 6.x   
Hardware: PC   
OS: Windows XP   
Issue Type: DEFECT Exception Reporter:
Bug Depends on:    
Bug Blocks: 127240    
Attachments: Test module.

Description Jiri Skrivanek 2008-02-13 09:44:20 UTC
URLMapper.findFileObject(url) returns null when url points to module jar. For example this one

URL=nbjcl:file:/D:/Development/builds/nbUserdir/module1/build/cluster/modules/org-yourorghere-module1.jar!/org/yourorghere/module1/URLMapperTest.class
myFO=null

To reproduce unzip attached module, open in IDE and run it. Call main menu 'Help|URL Mapper Test' and you will see
output in console.

Product Version: NetBeans IDE Dev (Build 20080213082603)
Java: 1.6.0_04; Java HotSpot(TM) Client VM 10.0-b19
System: Windows XP version 5.1 running on x86; Cp1250; cs_CZ (nb)
Comment 1 Jiri Skrivanek 2008-02-13 09:44:50 UTC
Created attachment 56580 [details]
Test module.
Comment 2 Jiri Skrivanek 2008-02-13 09:46:36 UTC
BTW, it might be somehow related to issue 126602.
Comment 3 rmatous 2008-02-13 11:09:21 UTC
Caused by:
http://hg.netbeans.org/main/rev/63497
by implementing:
http://wiki.netbeans.org/StartupCache

No registered URLMapper for nbjcl protocol


Comment 4 Petr Nejedly 2008-02-15 16:02:44 UTC
Well, was it ever specified that you can access internal module data as FileObjects?
Most of such use cases do export the file in question through layerFS, which is specified to work correctly.

While it would be possible to either provide URLMapper implementation that would forward nbjcl: accesses to appropriate
JarFS, or to make the class loader provide (and serve for URL based requests) jar: URLs, I'd rather remove all such use
cases.
The reason is simple: jar-per-module is about the worst possible deployment formats for number of reasons. If we one day
 get to implementing better format, we'd need to provide a special filesystem implementation that would allow processing
such (rare) requests.
Comment 5 Jaroslav Tulach 2008-02-15 20:08:00 UTC
My guess is that we do not want to support access to module JAR content as FileObjects. It really seems accidental 
that it even worked. That is why I suggest a note about incompatible change in module system and wontfix. Jesse, do 
you agree, will you do it?
Comment 6 Jesse Glick 2008-02-15 20:30:06 UTC
Agreed, this is something we can probably do without. #e6d9babd282b
Comment 7 Jiri Skrivanek 2008-02-19 13:21:58 UTC
Verified.
Comment 8 Jesse Glick 2008-04-25 19:06:40 UTC
x
Comment 9 Jesse Glick 2008-04-25 19:06:55 UTC

*** This issue has been marked as a duplicate of 129772 ***
Comment 10 Jiri Skrivanek 2008-04-25 19:13:01 UTC
Verified.