This content has been marked as final.
Show 13 replies
-
1. Re: VFS - minor performance improvement
alesj Jan 11, 2008 9:02 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
Can we add a VFS/VirtualFile.getChild() that doesn't throw an IOException?/** * Get a child * * @return the child or <code>null</code> if not found * @throws IOException if a real problem occurs */ public VirtualFile getChild() throws IOException {}
I can add this, and we can then slowly move the findChild usage to this new getChild + null check.
And I guess you mean getChild(String path)? ;-) -
2. Re: VFS - minor performance improvement
starksm64 Jan 11, 2008 11:32 AM (in response to adrian.brock)I thought we talked about changing getChild(...) to not throw the IOException.
-
3. Re: VFS - minor performance improvement
alesj Jan 11, 2008 11:37 AM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
I thought we talked about changing getChild(...) to not throw the IOException.
There is no getChild() method yet in VFS.
Only findChild(), which most of the code expects to throw IOE if the child is not found, so the direct change would probably introduce a lot of NPEs. -
4. Re: VFS - minor performance improvement
adrian.brock Jan 11, 2008 11:51 AM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
I thought we talked about changing getChild(...) to not throw the IOException.
You're thinking of the isLeaf() checking for child operations. It current throws an IOE if you
do findChild(), getChildren(), visit(), etc. on a leaf.
We should probably keep for that for findChild (backwards compatibilty - null is not an
expected return value) but return null, Collections.emptyList() or do a no-op visit
in the other methods. -
5. Re: VFS - minor performance improvement
alesj Jan 16, 2008 5:04 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
It current throws an IOE if you
do findChild(), getChildren(), visit(), etc. on a leaf.
We should probably keep for that for findChild (backwards compatibilty - null is not an
expected return value) but return null, Collections.emptyList() or do a no-op visit
in the other methods.
I've added a getChild to VFS and VirtualFile.
The current code has some duplicates.
I'll remove the findChild from spi parts, just leaving the findChild on the api. -
6. Re: VFS - minor performance improvement
alesj Jan 16, 2008 5:21 AM (in response to adrian.brock)"alesj" wrote:
I'll remove the findChild from spi parts, just leaving the findChild on the api.
I've got the MC and AS5 fixes in place, just need to do a release.
I can do a VFS beta7, or still deploy a snapshot for some additional changes?
Still waiting for some caching input. :-)
I'll also put changes from beta6 into our new VFS JIRA space. -
7. Re: VFS - minor performance improvement
dimitris Jan 16, 2008 5:47 AM (in response to adrian.brock)I'd prefer to have a tagged VFS Beta7 without caching changes first, then experiment with that part, so we can rollback if needed.
-
8. Re: VFS - minor performance improvement
alesj Jan 16, 2008 7:08 AM (in response to adrian.brock)"dimitris@jboss.org" wrote:
I'd prefer to have a tagged VFS Beta7 without caching changes first, then experiment with that part, so we can rollback if needed.
OK, once I've cleanup the findChild/getChild mess, I'll do a beta7 release + change the MC, AS5 usages that make sense. -
9. Re: VFS - minor performance improvement
starksm64 Jan 16, 2008 10:12 AM (in response to adrian.brock)I created a post for an mc 2.0.0.Beta10 release due next Monday. Lets coordinate on that as I need some metavalue changes.
-
10. Re: VFS - minor performance improvement
alesj Jan 16, 2008 10:24 AM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
Lets coordinate on that as I need some metavalue changes.
How does this effect VFS? -
11. Re: VFS - minor performance improvement
starksm64 Jan 16, 2008 10:27 AM (in response to adrian.brock)It does not affect the vfs release, that can be done anytime. I was referring to the mc update comment.
-
12. Re: VFS - minor performance improvement
alesj Jan 16, 2008 10:49 AM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
I was referring to the mc update comment.
I basically just changed the usage of findChild to getChild where it made absolute sense.
And since the method doesn't throw IOE for not finding the resource, I had to change the try/catch parts a bit + handling the null return. -
13. Re: VFS - minor performance improvement
alesj Jan 17, 2008 11:02 AM (in response to adrian.brock)Should I return null for reverse path tokens going over the top as well?
if (PathTokenizer.isReverseToken(tokens[index)) { VirtualFileHandler parent = current.getParent(); if (parent == null) // TODO - still IOE or null? throw new IOException("Using reverse path on top file handler: " + current + ", " + path); else current = parent; }
I guess since this is a rare usage, and you probably expect the reverse path to work, I could be still useful to throw IOE.