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 23628 - Suggest pluggable URL -> FileObject mapping
Summary: Suggest pluggable URL -> FileObject mapping
Status: CLOSED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 3.x
Hardware: PC Linux
: P1 blocker (vote)
Assignee: rmatous
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-05-16 17:23 UTC by Jaroslav Tulach
Modified: 2008-12-22 18:46 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:

Attachments
Diff provided (4.15 KB, patch)
2002-05-21 10:49 UTC, rmatous 		Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2002-05-16 17:23:00 UTC 
After implementation of issue 18220 it has been
realized that pluggable mapping is also needed
from URL to FileObject, I suggest to implement it
by adding methods:

static FileObject findFileObject (URL url);
abstract FileObject getFileObject (URL url);

both able to return null. Please do it now before
the URLMapper appears in the 3.4 release.
Comment 1 rmatous 2002-05-21 10:47:28 UTC 
Implemented. Diff will be attached. If no objections, then I will
integrate it into trunk, notice in API changes. Perhaps should be also
announced on openide-dev.
Comment 2 rmatous 2002-05-21 10:49:09 UTC 
Created attachment 5876 [details]
Diff provided
Comment 3 Jaroslav Tulach 2002-05-21 12:35:44 UTC 
The name of the method shall be findFileObjects, if it returns array,
I guess.

The results of all URLMappers should be merged together, if more than
one mapper is willing to contribute or it should be documented that
the first one wins.
Comment 4 rmatous 2002-05-21 13:39:37 UTC 
You are right. Then also second method shold be renamed to
getFileObjects.
Comment 5 Jesse Glick 2002-05-21 19:07:52 UTC 
Some comments on patch:

1. Contract in findFileObject is hard to follow. Suggest splitting it
up into separate points:

a. Zero or more FOs may be returned.

b. For a URL gotten from one of the FO -> URL methods, at least one FO
must be returned.

c. For each returned FO, it must be true that that FO -> URL gives the
exact URL which was passed in.

2. new File(url.getFile()).getCanonicalFile() is not guaranteed to
work by the Java platform APIs. There is no guaranteed correct
solution on JDK 1.3. On JDK 1.4, there is: new File(URI).

Agree with Yarda re. renames of the two new methods, and merging of
results being desirable.
Comment 6 rmatous 2002-05-22 10:04:39 UTC 
1.b. I hasitate if contract can contain: For a URL gotten from one of
the FO -> URL methods, at least one FO must be returned. 

There is a problem, because if e.g.(FO instanceof MFO) and delegate
from XMLFileSystem with defined url= in layer, then no problem FO ->
URL, but backward URL -> FO seems to me pretty complicated.
Comment 7 Jesse Glick 2002-05-22 18:31:49 UTC 
I guess you're right, that's too hard to guarantee.
Comment 8 rmatous 2002-07-15 13:18:48 UTC 
Already fixed
Comment 9 pzajac 2003-02-12 15:41:34 UTC 
verified. Created qa-unit test:
testFindFOfromURL
Comment 10 Quality Engineering 2003-07-01 16:21:13 UTC 
Resolved for 3.4.x or earlier, no new info since then -> closing.