[Design the new POJO MicroContainer] - Alternative vfs jar implementation
by mstruk
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:
https://svn.jboss.org/repos/jbossas/projects/vfs/branches/jar-alter-work
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.
Cheers :)
- marko
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
16 years, 7 months
[Design the new POJO MicroContainer] - Re: deployer test failures
by scott.stark＠jboss.org
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
16 years, 7 months
[Design the new POJO MicroContainer] - deployer test failures
by scott.stark＠jboss.org
I can't build the deployers trunk due to:
| [INFO] Surefire report directory: /Users/svn/JBossAS/projects/jboss-deployers/trunk/deployers-impl/target/surefire-reports
|
| Running org.jboss.test.deployers.scope.test.LoaderMetaDataRepositoryUnitTestCase
| Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec <<< FAILURE!
| Running org.jboss.test.deployers.scope.test.PopulateMetaDataRepositoryUnitTestCase
| Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec <<< FAILURE!
|
|
| Tests run: 154, Failures: 4, Errors: 0, Skipped: 0
|
| [INFO] ------------------------------------------------------------------------
| [ERROR] BUILD FAILURE
| [INFO] ------------------------------------------------------------------------
| [INFO] There are test failures.
|
| Please refer to /Users/svn/JBossAS/projects/jboss-deployers/trunk/deployers-impl/target/surefire-reports for the individual test results.
| [INFO] ------------------------------------------------------------------------
| [INFO] For more information, run Maven with the -e switch
| [INFO] ------------------------------------------------------------------------
| [INFO] Total time: 20 seconds
| [INFO] Finished at: Tue Apr 29 15:14:10 PDT 2008
| [INFO] Final Memory: 16M/41M
| [INFO] ------------------------------------------------------------------------
| [587][valkyrie: trunk]$
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147663#4147663
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4147663
16 years, 7 months
[Design of EJB 3.0] - Re: jndi name issues
by scott.stark＠jboss.org
"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:
| @XmlTransient
| 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
16 years, 7 months