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 53130 - nbresloc protocol cannot load resource with multiple dots in last path component
Summary: nbresloc protocol cannot load resource with multiple dots in last path component
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: Jesse Glick
URL:
Keywords: I18N
Depends on:
Blocks: 54045
  Show dependency tree
 
Reported: 2005-01-07 22:54 UTC by Peter Zavadsky
Modified: 2008-12-22 18:37 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
The patch (14.73 KB, patch)
2005-04-03 19:13 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Zavadsky 2005-01-07 22:54:53 UTC
We have run into this issue.
Wanted to customize resource provided by one
module, by another module dependent on it.

xml/core module has in its jar (among other files)
(under resources/templates folder) file named:
'emptyXML.xml.template'

When we are referring to the file from other
module (dependent on xml/core) by the nbresloc
protocol:
<file name="someNewName"
url="nbresloc:/org/netbeans/modules/xml/core/resources/templates/emptyXML.xml.template"/>

Then during runtime the file is not found, it is
thrown an exception that there is not found resource:
'nbresloc:/org/netbeans/modules/xml/core/resources/templates/emptyXML/xml.template'

Look at the the second to last dot, it was changed
to a slash.

If you look into the implementation (the
core/src/../NbURLStreamHandlerFactory), you'll see
the reason, all dots except the last one are
replaced by slashes.

Is there any workaround?

Could you fix it the way, you provide new protocol
unless this existing one can be adjusted.
Comment 1 Peter Zavadsky 2005-01-26 22:04:51 UTC
Or could you require those modules don't provide more than one dot
(for extension only) in the layers?
Comment 2 Marian Mirilovic 2005-02-17 07:21:29 UTC
reassigne to Jesse
Comment 3 _ pkuzel 2005-02-17 21:26:26 UTC
If URL contains at last one '/' do not substitute '.' by '/'. 
I declined to workaround it in XML module layer. 
Comment 4 Jesse Glick 2005-03-10 00:00:40 UTC
Will just have to stop using NbBundle.getLocalizedFile, I guess; it is simply
unusable for this scenario (and not a very smart API in general, but very old
and won't change it now). Can mostly copy and paste that code, simplifying it
(cannot use NbBundle's cache any more). Or can use a special-case code path in
case the nbresloc file contains >1 '.' after the last '/'.
Comment 5 Peter Zavadsky 2005-03-10 00:53:43 UTC
It is not the NbBundle.getLocalizedFile which bothers. But that I can't use that
protocol if need to reuse some file from dependent module in xml layer. See the
scenario I described at the beginning. (We are customizing the locations of
templates, moving some of them into different folders, it would be useful to be
able just to reuse the original files -> now we need to copy them).
Comment 6 Jesse Glick 2005-04-03 19:06:47 UTC
Well I have a working patch but it looks like I am too late to put it into 4.1,
since that is being branched right now and I am still running commit validation.
:-( If you feel this issue is important to you (and you cannot use a simple
workaround, such as was suggested in issue #54045) you may be justified in
raising priority to P2, in which case I would be permitted to merge the fix to
the release41 branch.

BTW: I believe the old nbresloc impl also has an obscure bug relating to
resources with a '.' in a nonterminal path component, e.g.
"nbresloc:/some.dir/file" would not be correctly brandable. I have covered this
possibility as well in the unit test which confirms the fix of the bug you reported.

Note that the patch makes the nbresloc protocol handler not use
NbBundle.getLocalizingFile at all; this also means that the cache which NbB.gLF
maintains will not be used. I don't know if that would have any significant
effect on startup time; would be nice to have some comparative measurement done
for that.
Comment 7 Jesse Glick 2005-04-03 19:13:51 UTC
Created attachment 21319 [details]
The patch
Comment 8 Peter Zavadsky 2005-04-04 17:16:10 UTC
Thanks for the patch and fixing of the issue, I think it is OK to have it in
next release.
Comment 9 Jesse Glick 2005-04-05 01:09:30 UTC
OK.

committed   * Up-To-Date  1.10       
core/src/org/netbeans/core/NbURLStreamHandlerFactory.java
added       * Up-To-Date  1.1        
core/test/unit/src/org/netbeans/core/NbURLStreamHandlerFactoryTest.java
committed   * Up-To-Date  1.58        openide/src/org/openide/util/NbBundle.java