I'm guessing we want to introduce some sort of configuration object (probably with a fluent API) or remove the ExtensionLoader?

Exactly.

Some requirements:

Must be created automatically with no user interaction if nothing explicit is specified

Must be able to accept injections (ie. be a plain ol' bean from a factory)

This is so that when running in a controlled environment like AS, we can configure it using DI

Specifically, the Executor used in ZIP Export must comply with one managed by the host environment (but don't bother actually making that exposed now). It's just the defining use case we must be able to support.

Maybe I'm missing something, but those requirements seem pretty close to what we have to day.

Must be created automatically with no user interaction if nothing explicit is specified

If no ExtensionLoader is set on the Archives factory, a default ServiceExtensionLoader will be used.

Must be able to accept injections (ie. be a plain ol' bean from a factory)

You can set any ExtensionLoader you want on the Archives factory and that instance will be used to create the MemoryMapArchive instance that backs all archive's. Which again does all the ExtensionLoader. You can also add overrides to specific Extensions via the Archives factory, as part of the ExtensionLoader contract.

This is so that when running in a controlled environment like AS, we can configure it using DI

AS has to have a Service of some sort that initializes the Archives factory.

Specifically, the Executor used in ZIP Export must comply with one managed by the host environment (but don't bother actually making that exposed now). It's just the defining use case we must be able to support.

This is the only new requirement. The ExtensionLoader is based on loading extensions for Archive views, not 'random' Services any impl would want.

I've been thinking about this off and on today and I'm really not sure which way I like. I'm pretty sold on the idea of a Configuration object, but not exactly sure what to put on it. Does it just contain some configuration about the archive such as name and type and optionally any ExtensionLoader info, or is it more of a complete builder idea that would also contain all of the items that belong in the archive? I kind of don't like this idea because it would be difficult to keep things flexible and still maintain the fluent API (a WEB-INF doesn't make any sense in a jar for example).

Another idea I've had is if we really need the Archives class or if this class can be deprecated and the creation methods can be moved into the Archive interface so you'd end up doing something like

My hope is to separate out "Archives" from configuration of ShrinkWrap entirely.

LightGuard wrote:

Does it just contain some configuration about the archive such as name and type and optionally any ExtensionLoader info, or is it more of a complete builder idea that would also contain all of the items that belong in the archive?

I don't think they have anything to do with Archive. Extension loading is part of the ShrinkWrap configuration. "name" and "type" of archive aren't configurable elements, they're part of an archive's state.

Right now the only ShrinkWrap configuration we have is the extension loading bits. Soon we'll need to put in Executors. But either way, I'm eager to get a single ShrinkWrapConfiguration (or similarly-named) object which is en entry point to config the system, and let it default intelligently if the user doesn't request to touch it.

It looks like right now the single entry into the Shrinkwrap system (sorry if I'm wrong, I haven't poured over the whole code base yet) is Archives. What we'd be introducing something like ShrinkWrapConfiguration... that could be setup once in a method and would live through out the life of the VM (assuming everything is static). Is that how we'd want to do it though? Currently there's that resetState method that's there for testing, seems like if we were to use instances instead of static state holding this could be avoided, but then we'd have to pass around an instance of the config object. Kinda torn on this idea.

If depends on how we want to define the configurable state for the ShrinkWrap subsystem.

I don't think JVM-wide is something any of us want.

On the other side of the coin, we want default configuration to continue to be hidden from the user; and they touch it only when they need. Configuration needs to be associated with some context:

Per JVM (static only, which we don't like)

Per Thread (we wouldn't need to pass it around via the API; the current config is in a ThreadLocal)

Archive (internally an archive impl holds a pointer to its configuration)

I'm thinking some hybrid solution where the default configuration is associated with a Thread, and we give users a static API to change defaults. Upon creation of an archive, each archive gets its own *copy* of the default configuration (so that subsequent changes to the default don't affect archives already created).

This is somewhat similar to how we handle Security contexts in the AS; the security context is associated with a Thread and then local/remote invocation objects are responsible for propagating it throughout the request.