1 2 3 Previous Next 32 Replies Latest reply on Apr 20, 2010 6:59 PM by lightguard

    Discussion about SHRINKWRAP-102

    lightguard
      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
          alrubinger

          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
            lightguard
            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

              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}

               

               

              ??

              • 4. Re: Discussion about SHRINKWRAP-102
                alrubinger

                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

                  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
                    alrubinger

                    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
                      lightguard

                      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
                        alrubinger

                        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
                          lightguard
                          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
                            alrubinger

                            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
                              lightguard

                              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
                                lightguard
                                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
                                  "Who" in AS are going to configure this pr Thread?
                                  • 14. Re: Discussion about SHRINKWRAP-102
                                    alrubinger

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

                                     

                                    S,

                                    ALR

                                    1 2 3 Previous Next