4 Replies Latest reply on Mar 11, 2010 5:44 AM by alesj

    Replacement for JarUtils

    johnbailey
    johnbailey Feb 16, 2010 6:22 PM

      The JarUtils class was removed from VFS3.  It didn't seem to fit in the VFS projects.  Most of the calls to it were to get the  jar suffixes to create a SuffixesExcludeFilter.

       

      Would a better solution be to use injection to get either the suffixes or even better a SuffixesExcludeFilter to exclude JARs? 

       

      If it does make sense to re-introduce the JarUtils, where is the best home?

      • 6167 Views
      • Tags:
        • 1. Re: Replacement for JarUtils
          dmlloyd
          dmlloyd Feb 16, 2010 6:26 PM (in response to johnbailey)
          Don't reintroduce it unless someone requires it.  Its only use is to store file extensions which shouldn't be static in the first place - it should be configurable by something in the deployer layer.  I thought we moved that list over someplace else already in fact?
            • Actions
          • 2. Re: Replacement for JarUtils
            johnbailey
            johnbailey Feb 16, 2010 6:31 PM (in response to dmlloyd)

            The set of suffixes was added JARStructure  A static means for others to get at it was not added.  Is that the best place for it to live, and for other deployers to get access?

              • Actions
            • 3. Re: Replacement for JarUtils
              johnbailey
              johnbailey Feb 16, 2010 9:40 PM (in response to dmlloyd)
              Since JARStructure has a public getSuffixes method, it really could be used as the authoritative source for the suffix set.  Other beans can get the set by injecting the suffixes property from JARStructure.  So I think we are set.
                • Actions
              • 4. Re: Replacement for JarUtils
                alesj
                alesj Mar 11, 2010 5:44 AM (in response to johnbailey)

                OK, I agree with not-needing-JarUtils,

                but we need to be consistent and track down all the places where this JU somehow kicked in (directly or transitively).

                 

                VFSClassLoaderClassPathDeployer being one of this places -- as from jboss-dev ml discussion.

                 

                I'm not saying we need to go out now and do super extensive search,

                we just need to be alert on similar things poping in -- I'll fix the VFSClassLoaderClassPathDeployer for now.

                  • Actions