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 - URLMapper.findFileObject(url) returns null
Summary: URLMapper.findFileObject(url) returns null
Status: VERIFIED DUPLICATE of bug 129772
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P2 blocker (vote)
Assignee: Jesse Glick
Depends on:
Blocks: 127240
  Show dependency tree
Reported: 2008-02-13 09:44 UTC by Jiri Skrivanek
Modified: 2008-12-23 08:44 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Test module. (6.00 KB, application/x-compressed)
2008-02-13 09:44 UTC, Jiri Skrivanek

Note You need to log in before you can comment on or make changes to this bug.
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


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:
by implementing:

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
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
Comment 8 Jesse Glick 2008-04-25 19:06:40 UTC
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