LightGuard wrote:

 

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.

Let's see some design proposals!

S,

ALR

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.

The ExtensionLoader API today is simple enough:

{code}
   /**
    * Load a Extension.
    * 
    * @param <T>
    * @param extensionClass The Extension interface
    * @param baseArchive The base archive to use
    * @return a 
    */
   public <T extends Assignable> T load(Class<T> extensionClass, Archive<?> baseArchive);
{code}

To meet this requirement we could add this to it:

{code}
   /**
    * Load a Extension.
    * 
    * @param <T>
    * @param serviceInterfaceClass The Service interface
    * @return a 
    */
   public <T> T load(Class<T> serviceInterfaceClass);
{code}

ZipExporter would have to be able to get a hold of the ExtensionLoader some how, either via the Archive interface, or the Archives factory.

{code}
protected void export() 
{
   ExecutorService service = Archives.getExtensionLoader().load(ExecutorService.class);
   ...
   service.submit()
   ...
}
{code}

??

aslak wrote:

 

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

Nope; you're not missing anything.  They're the same requirements, but additionally:

• Configuration shouldn't be part of the Archives API
• We should have a single Configuration object (from which we may then drill down to configure disparate elements)

aslak wrote:

ZipExporter would have to be able to get a hold of the ExtensionLoader some how, either via the Archive interface, or the Archives factory.

protected void export() 
{
   ExecutorService service = Archives.getExtensionLoader().load(ExecutorService.class);
   ...
   service.submit()
   ...
}

This is really what SHRINKWRAP-102 requests; not to come in through "Archives".  It's about separation of configuration from archives entirely.

The rest of the concepts Aslak outlined should stay in place.

S,

ALR

The new Configuration object still has to come in via the Archives factory, since that's where the Archive creation is done?

Or are you thinking a static Configurations that we refere to around where we need something loaded?

Exactly, static initialization.  So if the user touches it and uses things explicitly; fine.  If not, the first time it's referenced things will default in place (just like you have now).

Only extracted out from Archives.

S,

ALR

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.

S,

ALR

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.

S,

ALR

Is there another context with which you'd like to attach the configuration?

S,

ALR