1 2 3 Previous Next 32 Replies Latest reply on Apr 20, 2010 6:59 PM by lightguard Go to original post
      • 30. Re: Discussion about SHRINKWRAP-102
        alrubinger

        We should set the names to whatever makes the most sense.  This point is open for debate by all.

         

        Under my patch, the real archive factory is called "ArchiveFactory", and it's associated with a Domain.  The Domain's Configuration will be used by every Archive created by the Domain's ArchiveFactory.

         

        So you do:

         

        Domain domain = ShrinkWrap.createDomain();
        Configuration config = domain.getConfiguration();  // Read-only
        Archive<?> archive = domain.getArchiveFactory().create("name",Type.class);
        

         

        The "Archives" name may have more intent to it as a factory, but in my view doesn't fit the convention of "Collections" or "Executors" in the JDK.  These are static factories, while our ArchiveFactory has state - namely a configuration.  I don't believe it makes sense to have the following:

         

        Archives.getDomain();
        Archives.getConfig();
        

         

        ...because a domain and configuration aren't visible properties of an Archive.

         

        So "ShrinkWrap" is now in place as the static factory pointing to the default domain.  We could keep one method of Archives and move it out of "ShrinkWrap":

         

        Archives.create(String,Class);

         

        ...which would delegate to the default domain.

         

        Also, I think we're underestimating how much we'll need the domain/configuration split away from the default (or at least access to the default config).  Already we're getting bug reports that the JVM won't shut down because the ShrinkWrap ExecutorService is still plugging away.  We don't see this via Surefire because they kill the JVM on test completion, but if you run a Main client the problem is easily reproducible (reports Jaikiran).

         

        Keep in mind that our focus here should be on what's most natural/correct as an API.  We don't have to be loyal to "Archives" for backwards-compat sake at this point; this is actually our only chance to get the API in best shape as we can until 2.0.0.


        S,

        ALR

        • 31. Re: Discussion about SHRINKWRAP-102
          alrubinger

          These changes are now committed, and I'd like to go for 1.0.0-alpha-8 tomorrow, so anyone who has feedback on the new APIs, speak now.

           

          Of particular interest is:

           

          ShrinkWrap.create(String name,Class<?> type);

           

          ...which creates an archive under the default domain.  I think I like this setup, as not every "type" is necessarily an archive view.

           

          S,

          ALR

          • 32. Re: Discussion about SHRINKWRAP-102
            lightguard

            I like that.  Actually I like it a lot better than Archive for a couple of reasons.

             

            1. Like you said, not everything is an archive
            2. It really says where this is coming from, the old Archive could have been any class.  With this change everyone knows this is coming from Shrinkwrap

             


            1 2 3 Previous Next