1 2 3 Previous Next 32 Replies Latest reply: Apr 20, 2010 6:59 PM by Jason Porter Go to original post RSS
  • 15. Re: Discussion about SHRINKWRAP-102
    Andrew Rubinger Master

    I don't think fluency is a requirement here.  The use case for archives is that users typically want to construct in a bunch of steps, so we minimize the code to do it.  With this configuration I don't see someone frequently configuring the extension loader, then the executors, then whatever all, all at once.

     

    S,

    ALR

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

    Or, we can make the default configuration static and JVM-wide, so long as we continue to copy it on a per-archive basis.

     

    The problem there is that two default configs can never coexist.  Thread association has problems of its own, so let's hear some new ideas.

     

    S,

    ALR

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

    No not really.. just wondering if you had a clear use case in mind..

    (besides we should have a some what global config)

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

    Yeah, the use case isn't:

     

    "I need to configure on a per-Thread basis"

     

    ...it's:

     

    "I need to be able to configure, but I don't want to have to".

     

    Just like it is now; only with a separate, unified configuration mechanism apart from the archive creation mechanism.

     

    S,

    ALR

  • 19. Re: Discussion about SHRINKWRAP-102
    Jason Porter Master
    I think we could have a single, static default config, then the archives could have a pointer to it unless the users changes something in the config, then you'd want to make a copy / clone of the default config to make the change so you don't mess with any of the other archives.  Or we could make the configuration object immutable.  Either way it looks like we're going to have to store the configuration on the archive itself to achieve maximum flexibility.
  • 20. Re: Discussion about SHRINKWRAP-102
    Jason Porter Master

    ALRubinger wrote:

     

    The problem there is that two default configs can never coexist.

    Is there a use case for more than one default config?  Maybe a default config per archive type? Maybe that could come later though as right now there's really not a lot to configure.

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

    Same as any time you have JVM global variables.

     

    Maybe two embedded containers rely upon ShrinkWrap, each needing their own configs.  Without separation they can't exist in the same JVM.

     

    S,

    ALR

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

    Sounds like what we have discussed are as follows:

     

    • JVM level (static) configuration -- problems with more than one default configuration
    • Thread local configuration -- Same kind of thing if you have more than one ShrinkWrap instance going in the same thread (multiple archives)
    • Instance based

     

    We haven't really talked about the instance based thing other than storing a ref to it on the archive, which is probably the only place it's going to happen unless we create a ShrinkWrap class that you interface everything with (kind of what Archives is today, but not static, you'd have to instantiate it.)  Then we run into the same problem though of a default configuration, unless that's part of the instantiation, but that seems like a bad thing to offload onto the user.

     

    I'm drawing blanks at the moment now.

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

    I think the real problem is that we have this detached notion of the "ShrinkWrap system", which isn't defined.

     

    Assuming I were to do this from a DI environment, I'd just have my ShrinkWrap system be a bean, and there could be many.  Archives could be created under the domain of a particular system, and inherit that configuration.  So archives themselves aren't configured, the system is.

     

    JBoss Microcontainer has a "Kernel", which is the main entry point, and there can be many coexisting within a JVM.  It provides all the proper separation, but there's the usability caveat: to interact with anything you need a Kernel reference.  There's no static usage like we have in Archives.

     

    So how about:

    ShrinkWrapDomain domain = ShrinkWrap.createDomain();
    ShrinkWrapConfiguration config = domain.getConfiguration();
    domain.setExtensionLoader(whatever);
    ArchiveFactory factory = domain.getArchiveFactory(); // Replaces "Archives"
    factory.create("name.jar",JavaArchive.class); // Replaces "Archives"
    

     

    This makes the simplest usage more verbose than what we currently have:

     

    JavaArchive archive = ShrinkWrap.createDomain().getArchiveFactory().create("name.jar",JavaArchive.class);

     

    ..and we could even make shortcuts by using a static "default" domain which never ever is configurable:

     

    JavaArchive archive = ShrinkWrap.createArchive("name.jar",JavaArchive.class); // Uses the default, unconfigurable domain
    

     

    ...this gives us the isolation that we need.  And then we can properly hold a reference to the ShrinkWrapDomain as an MC bean (or in any DI container).

     

    S,
    ALR

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

    So how about:

    ShrinkWrapDomain domain = ShrinkWrap.createDomain();
    ShrinkWrapConfiguration config = domain.getConfiguration();
    domain.setExtensionLoader(whatever);
    ArchiveFactory factory = domain.getArchiveFactory(); // Replaces "Archives"
    factory.create("name.jar",JavaArchive.class); // Replaces "Archives"
    

     


    What is the difference between Domain and Configuration? Can you have multiple Configurations within a Domain ?

     

     

     

    This makes the simplest usage more verbose than what we currently have:

     

    JavaArchive archive = ShrinkWrap.createDomain().getArchiveFactory().create("name.jar",JavaArchive.class);
    

     

    I agree, a bit verbose..

     

     

     

    ..and we could even make shortcuts by using a static "default" domain which never ever is configurable:

     

    JavaArchive archive = ShrinkWrap.createArchive("name.jar",JavaArchive.class); // Uses the default, unconfigurable domain
    

     

    ...this gives us the isolation that we need.  And then we can properly hold a reference to the ShrinkWrapDomain as an MC bean (or in any DI container).

     

    S,
    ALR

    This syntax I can live with, but..

     

    The point of the separation is not for the environment to control the ShrinkWrap configuration, but merely be able to create its own and co exist?

    All of my code would be using the 'short' version of creating a archive, basically because it's less to write, and it then seems like I would be running my own/default configuration?

     

    The short version could look for a ThreadLocal Domain if no found create one..  ?

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

    aslak wrote:

     

    So how about:

    ShrinkWrapDomain domain = ShrinkWrap.createDomain();
    ShrinkWrapConfiguration config = domain.getConfiguration();
    domain.setExtensionLoader(whatever);
    ArchiveFactory factory = domain.getArchiveFactory(); // Replaces "Archives"
    factory.create("name.jar",JavaArchive.class); // Replaces "Archives"
    

     


    What is the difference between Domain and Configuration? Can you have multiple Configurations within a Domain ?

     

     

     

     

    I made a whoopsie.  Should be:

     

    config.setExtensionLoader(whatever);

     

    Domain holds one configuration, one archive factory, and anything else we decide in the future should be contained within the ShrinkWrap "system".  (Though I like the term "domain" instead of "system").

     

    aslak wrote:

    This syntax I can live with, but..

     

    The point of the separation is not for the environment to control the ShrinkWrap configuration, but merely be able to create its own and co exist?

    All of my code would be using the 'short' version of creating a archive, basically because it's less to write, and it then seems like I would be running my own/default configuration?

     

    The short version could look for a ThreadLocal Domain if no found create one..  ?

    The separation is to both allow configuration and have disparate configs co-exist.

     

    Yep, I think most code would be done using the "short" version; off an immutable default configuration (convention over config).  And the short version is essentially a pointer to a static (JVM-wide) domain.  That domain may be shared safely because it's immutable.

     

    Environments like DI containers (JBossAS) will be injecting the ShrinkWrapDomain whenever they need to deal with archive creation or configuration.

     

    The Thread-based context makes little sense here.  In my security example above, the association fits because a request is logically mapped to a Thread.  Here we don't have those sematics, so we'd be abusing ThreadLocal just to avoid having a proper API.

     

    S,

    ALR

  • 26. Re: Discussion about SHRINKWRAP-102
    Jason Porter Master
    Sounds good to me, is this the design we want to go with (I'm not liking all the boilerplate, but at least we have a short cut way that should work for most cases, better than other Java APIs )?  If it is I'll get this coded up.  I'll deprecate the existing Archives, unless you think it best to just strip it out.
  • 27. Re: Discussion about SHRINKWRAP-102
    Andrew Rubinger Master

    Even if this doesn't end up being *exactly* it, I think we're on the right track in terms of providing both separation of domains and a quickie "easy-access" mechanism.  So if you start up, I don't think the work will be wasted as we can make tweaks here and there.

     

    S,

    ALR

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

    With SVN down for maintenance, I've got a patch attached to https://jira.jboss.org/jira/browse/SHRINKWRAP-102.

     

    The main types proposed:

     

    ShrinkWrap

    Domain

    Configuration

    ConfigurationBuilder

     

    For now I've @Deprecated Archives and it acts as a delegate to ShrinkWrap.getDefaultDomain stuff.  After committed we'll probably leave Archives deprecated, then remove it for the subsequent release.

     

    S,

    ALR

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

    Do we need to change the archive factory name to ShrinkWrap ?

     

    Can't the Domain/Config just as well be a part of Archives ? (deprecate the extension mapping)

     

    As the name goes, Archives has more intent to it then ShrinkWrap. Even if it's 'just' a short cut for ShrinkWrap.createDomain().getArchivesFactory().create(""), I think 99% of the users will use the shortcut.