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 questions.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147669#4147669
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147669
I see the same error from within eclipse if I run the test. The test classpath is missing the gnu trove classes, and I see this referenced in no pom.xml.
| Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec <<< FAILURE!
| warning(junit.framework.TestSuite$1) Time elapsed: 0.003 sec <<< FAILURE!
| junit.framework.AssertionFailedError: Exception in constructor: testClassAnnotation (java.lang.NoClassDefFoundError: gnu/trove/TLongObjectHashMap
| at org.jboss.aop.AspectManager.<init>(AspectManager.java:116)
| at org.jboss.aop.AspectManager$1.run(AspectManager.java:281)
| at org.jboss.aop.AspectManager$1.run(AspectManager.java:269)
| at java.security.AccessController.doPrivileged(Native Method)
| at org.jboss.aop.AspectManager.initManager(AspectManager.java:267)
| at org.jboss.aop.AspectManager.instance(AspectManager.java:246)
| at org.jboss.aop.AspectManager.instance(AspectManager.java:235)
| at org.jboss.test.deployers.scope.support.TestComponentCreator.<init>(TestComponentCreator.java:51)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147667#4147667
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147667
"Carlo" wrote : We must have a notion of parent deployment units at metadata level
I assumed that the metadata api is a representation of the XML and not more than that. Everything else should be a layer on top. I still think it's a good idea to separate parsing/unmarshalling issues (and later maybe marshalling) from the "using it" logic. Having everything in the same place may complicate the api and maintenance.
I suggest we develop some wrapping api that gives the view we need but not add these changes to the classes that map to XML. The api may live in the metadata project as well,
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147629#4147629
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147629
"wolfc" wrote :
| We must have a notion of parent deployment units at metadata level, because else we'll have a problem with the persistence unit deployer (EJB3 Persisitence 6.2.2 Persistence Unit Scope).
We have that in the form of the EjbDeploymentSummary.
"wolfc" wrote :
| "scott.stark(a)jboss.org" wrote : For 3 we need a utility class that properly looks at the reference type to determine if this is a home/local-home, remote or local, business interface lookup.
| Not really, you can just lookup "[ejbName]/[interface]".
Then your not considering overrides form other sources such as annotations or xml. A binding of the form "[ejbName]/[interface]" is not going to be unique within an ear let alone the server.
If your talking about a "[ejbName]/[interface]" key against the JBossEnterpriseBeanMetaData:
| public String getJndiName(String ejbName, String iface)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147616#4147616
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147616