"johnbailey" wrote : 1. Change the internal storage archive of an existing container archive (this seems like the primary use case): I think this is the only case we need to be concerned with at this point. If even that. I hate to throw a wrench in this system, but I've recently had a moment of clarity and discussed a bit on IRC with Aslak earlier. The thing is that storage engines aren't as interesting to the user as export format options. For instance: JavaArchive archive = ArchiveFactory.createJavaArchive("name.jar") The above creates a Java container view, backed by default storage archive. The storage impl isn't important. It could be MemoryMap for the time being. What's nice about this is that the user doesn't care about the storage engine and just gets the view they want. But what *is* important is an "export" option. After the user is done mucking around and adding resources, classes, and the like, he'll want to deploy it. At this point the deployment tools can: InputStream in = ZipExporter.exportZip(archive); ...obtaining the InputStream of a real JAR. In the case of Embedded, this gets passed into deployment and AS never knows that an archive was used at all. Or a user can serialize the thing to disk and make an actual JAR file. Alternatively: File file = ExplodedExporter.exportExploded(archive,File parent); ...to obtain the root of an exploded representation. So the shift in approach I'm proposing is that storage engines aren't as important as how archives are exported. We can process the add(), contains(), delete(), etc operations however are most efficient, and only when the user is done does he want some real view of it. WDYT? S, ALR View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251927#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...