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 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4243160#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...