I wrote an alternative implementation of jar handling - from scratch in order to simplify
and reduce the amount of code, and specifically to address the problems I kept running
into when trying to fix JBVFS-4.
I currently have what appears to be a fully working jar handling implementation, that
exists in parallel to vfsjar - I named it vfszip. It works with jboss trunk, it does away
with issues I was working on in vfsjar, and has no problems with file locks on windows -
undeployment and redeployment work as they should. I don't think it's production
ready but it may be getting close. Some things still need to be finalized - temp files for
inner jars, serialization, priviliged blocks, and maybe other things I don't see yet.
Performance-wise it is comparable to vfsjar, I did not do any memory profiling yet. Also
archive file closing / reopening is a little bit too aggressive at the moment, so
performance can still be improved by a few percent.
Some details about my implementation ...
I made no change to VFS API - I did make some additions and changes in abstract context
and handler classes that don't affect other vfs context implementations. I changed
FileSystemContext to use vfszip impl instead of JarHandler - it could be made configurable
through system properties.
I centralized all the logic in one place - in ZipEntryVFSContext, so it's easy to
control access to resources (files). This way handlers are little more than proxies to a
context. I tightly coupled ZipEntryHandler to ZipEntryVFSContext. I think it's not
such a good idea to pass FileSystemContext to a JarHandler for example - significantly
limiting how the two can interact. My ZipEntryHandler presupposes it is created through
ZipEntryContext, so it works with ZipEntryContext directly and can interface with it in
implementation specific ways. I remodeled the code in such a way that the same code can be
used to handle inner jars and outer jars by mounting ZipEntryVFSContext into another
ZipEntryVFSContext - I introduced a mounting mechanism using ReferenceHandler and a little
extra code in abstract classes. This way a jar file inside FileSystemContext is handled by
mounting a ZipEntryVFSContext. The code is more modular and more contained.
JBVFS-4 is a natural non-issue in this alternative implementation. Handling of inner jars
of arbitrary depth is automatic. When file locking issue came to my attention I was able
to fix it in a few hours with this implementation. Due to centralized access to jar files
the issue was trivial to fix.
My implementation makes no use of jar:file: URLs. My handler does not extend
AbstractURLHandler - I don't use URL for getLastModified(), getSize(), openStream().
My implementation controls access to JarFile centrally inside context and opens and closes
it as necessary. For URLs, vfsURLs I always generate vfszip: url schema so any URL access
goes through VirtualFileURLConnection and through my context again.
The code is in svn:
If anyone is interested, give it a try, take a look at the code, tell me what you think,
what's missing, what's not working properly ... I'll be glad to answer any
View the original post :
Reply to the post :