1 2 3 Previous Next 32 Replies Latest reply: Apr 20, 2010 6:59 PM by Jason Porter RSS

Discussion about SHRINKWRAP-102

Jason Porter Master
I'm guessing we want to introduce some sort of configuration object (probably with a fluent API) or remove the ExtensionLoader?
  • 1. Re: Discussion about SHRINKWRAP-102
    Andrew Rubinger Master

    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

  • 2. Re: Discussion about SHRINKWRAP-102
    Jason Porter Master
    Okay, let me dig through it a bit more and see exactly what it's doing and come up with a proposal.
  • 3. Re: Discussion about SHRINKWRAP-102
    Aslak Knutsen Master

    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:

     

       /**
        * 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);

     

     

    To meet this requirement we could add this to it:

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

     

    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()
       ...
    }
    

     

     

     

    ??

  • 4. Re: Discussion about SHRINKWRAP-102
    Andrew Rubinger Master

    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

  • 5. Re: Discussion about SHRINKWRAP-102
    Aslak Knutsen Master

    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?

  • 6. Re: Discussion about SHRINKWRAP-102
    Andrew Rubinger Master

    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

  • 7. Re: Discussion about SHRINKWRAP-102
    Jason Porter Master

    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
    JavaArchive.create(ArchiveConfiguration.name("archive.jar").withExtensionLoader(...)).addClasses(...)
    

    I like this approach personally.  It's not completely fleshed out, but what are your thoughts?

  • 8. Re: Discussion about SHRINKWRAP-102
    Andrew Rubinger Master

    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

  • 9. Re: Discussion about SHRINKWRAP-102
    Jason Porter Master
    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.
  • 10. Re: Discussion about SHRINKWRAP-102
    Andrew Rubinger Master

    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

  • 11. Re: Discussion about SHRINKWRAP-102
    Jason Porter Master

    I got hung up on names a bit, but I think something like the following (I did this in vim, no clue if it really compiles) would do the trick:

     

    public interface ShrinkWrapConfiguration
    {
      private static final ThreadLocal<Configuration> config = new ThreadLocal<Configuration>() 
      {
        @Override protected Configuration initialValue() 
        {
          return new Configuration()
        }
      }
    
      public static getConfiguration()
      {
        return config.get();
      }
    
      public class Configuration
      {
        private static final String EXTENSION_LOADER_IMPL = 
              "org.jboss.shrinkwrap.impl.base.ServiceExtensionLoader";
    
        private ExtensionLoader loader;
    
        public Configuration() 
        {
          this(SecurityActions.newInstance( EXTENSION_LOADER_IMPL,
                                  new Class<?>[]{}, new Object[]{}, 
                                  ExtensionLoader.class);
        }
    
        public Configuration(ExtensionLoader initialLoader) 
        {
          this.loader = initialLoader;
        } 
    
        public ExtensionLoader getExtensionLoader()
        {
          return this.loader;
        }
    
        public void setExtensionLoader(ExtensionLoader newLoader)
        {
          this.loader = newLoader
        } 
      }
    }
    
  • 12. Re: Discussion about SHRINKWRAP-102
    Jason Porter Master
    Maybe something with a better fluent API, now that I think about it, but the above could work.
  • 13. Re: Discussion about SHRINKWRAP-102
    Aslak Knutsen Master
    "Who" in AS are going to configure this pr Thread?
  • 14. Re: Discussion about SHRINKWRAP-102
    Andrew Rubinger Master

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

     

    S,

    ALR

1 2 3 Previous Next