6 Replies Latest reply on Jul 13, 2009 2:06 PM by alrubinger

Shortcomings of Virtual Archives (in progress)

alrubinger Jul 13, 2009 2:30 AM

Given the following code:

final VirtualVfsArchive deployment = new VirtualVfsArchiveImpl(name).addClasses(OutputBean.class,
 OutputLocalBusiness.class);
log.info(deployment.toString(true));

...we get:

01:21:52,305 INFO [ServerTestCase] MemoryContextHandler@2105530421[path= context=vfsmemory://testDeployment.jar real=vfsmemory://testDeployment.jar]
 - 0 bytes
org - 0 bytes
org/jboss - 0 bytes
org/jboss/embedded - 0 bytes
org/jboss/embedded/testsuite - 0 bytes
org/jboss/embedded/testsuite/fulldep - 0 bytes
org/jboss/embedded/testsuite/fulldep/ejb3 - 0 bytes
org/jboss/embedded/testsuite/fulldep/ejb3/slsb - 0 bytes
org/jboss/embedded/testsuite/fulldep/ejb3/slsb/OutputBean.class - 844 bytes
org/jboss/embedded/testsuite/fulldep/ejb3/slsb/OutputLocalBusiness.class - 312 bytes

It's nice from an API standpoint, and this is what we're aiming for at this stage in the game.

However, the underlying impl is hacky. We've already loaded the class, yet what's happening under the covers is:

1) Get the CL which loaded the class
2) Get the URL of the resource representing the class
3) Read in the bytes of the .class file
4) Put those bytes into the virtual archive

It's all done in VirtualVfsArchiveImpl. So this creates an inefficient memory structure where we're duplicating already-read bytes. Conversation w/ Jason and DML in #jboss-dev lead to the resolution that we'll need some indirection in here at some point to say "requests for this class within this virtual archive can look first at some internal Map of Classes". Carlo later pointed out that probably a virtual file handler is in order.

So this is still a TODO. https://jira.jboss.org/jira/browse/EMB-35

S,
ALR

1. Re: Shortcomings of Virtual Archives (in progress)

jason.greene Jul 13, 2009 11:59 AM (in response to alrubinger)

There really is no need for the "classes" to appear in VFS. If someone wants to get a stream for a class instance, they would normally do clazz.getClassLoader().getResource(clazz.getName()) anyway, because there is no guarantee that a class visible to the deployment is actually in the deployment
Actions
2. Re: Shortcomings of Virtual Archives (in progress)

alrubinger Jul 13, 2009 12:35 PM (in response to alrubinger)

"jason.greene@jboss.com" wrote:
There really is no need for the "classes" to appear in VFS. If someone wants to get a stream for a class instance, they would normally do clazz.getClassLoader().getResource(clazz.getName()) anyway, because there is no guarantee that a class visible to the deployment is actually in the deployment

In some cases, the classes do need to be in the virtual archive.

This has to work the same way a physical deployment would. In a real JAR, we've got class files. So the deployment CL picks those up and uses them if the FQN is not already handled by a parent CL.

The only difference in the testing scenario is that the classes *are* all visible to a parent CL (usually the appCL) because the test launcher will put everything on java.class.path. In this case copying the bytes again within memory is a waste.

However, I could conceivably add classes as resources from elsewhere on the file system, and these are not covered under java.class.path. In that case, the bytes need to be copied and in memory within the virtual archive.

S,
ALR
Actions
3. Re: Shortcomings of Virtual Archives (in progress)

jason.greene Jul 13, 2009 1:33 PM (in response to alrubinger)

"ALRubinger" wrote:

However, I could conceivably add classes as resources from elsewhere on the file system, and these are not covered under java.class.path. In that case, the bytes need to be copied and in memory within the virtual archive.

If you have a class instance, then putting its bytes in the VFS is a waste. If you don't have a class instance, then you have a very different API, that operates off of Files/URLs.
Actions
4. Re: Shortcomings of Virtual Archives (in progress)

alrubinger Jul 13, 2009 1:42 PM (in response to alrubinger)

"jason.greene@jboss.com" wrote:
If you have a class instance, then putting its bytes in the VFS is a waste.

So you agree with me that the subject of this Thread is appropriate? :)

"jason.greene@jboss.com" wrote:
If you don't have a class instance, then you have a very different API, that operates off of Files/URLs.

addClass(Class<?> class) simply delegates out to addResource(String resource):

http://anonsvn.jboss.org/repos/jbossas/projects/embedded/trunk/core/src/main/java/org/jboss/embedded/core/incubation/virtual/impl/base/AbstractVirtualArchive.java
http://anonsvn.jboss.org/repos/jbossas/projects/embedded/trunk/core/src/main/java/org/jboss/embedded/core/incubation/virtual/impl/vfs/VirtualVfsArchiveImpl.java

Both are covered by the API:

http://anonsvn.jboss.org/repos/jbossas/projects/embedded/trunk/core/src/main/java/org/jboss/embedded/core/incubation/virtual/spi/ExtensibleVirtualArchive.java

S,
ALR
Actions
5. Re: Shortcomings of Virtual Archives (in progress)

jason.greene Jul 13, 2009 1:53 PM (in response to alrubinger)

"ALRubinger" wrote:

"jason.greene@jboss.com" wrote:
If you don't have a class instance, then you have a very different API, that operates off of Files/URLs.

addClass(Class<?> class) simply delegates out to addResource(String resource):

Perhaps we are both saying the same thing (just differently)?

My point was that these two methods should completely different behaviors. The class case should never need representation in the VFS, since the class instance (no matter where it came from), will work fine. In essence this is really the same as a specialized classloading configuration that pulls in files from outside the deployment. The major difference being that annotation scanning by frameworks such as ejb3 must be ran on these classes.

The resource case, on the otherhand, makes perfect sense for custom VFS behavior, since these really are files.
Actions
6. Re: Shortcomings of Virtual Archives (in progress)

alrubinger Jul 13, 2009 2:06 PM (in response to alrubinger)

OK cool, looks like we're both on the same page regarding the use cases and the issues then.

So next to solve is "how". :) And then doing it.

S,
ALR
Actions

Go to original post