1 2 3 Previous Next 32 Replies Latest reply on Jun 14, 2010 8:13 AM by alesj Go to original post
      • 15. Re: Wildcard support in Dynamic-imports
        alesj
        2) How to get the DelegateLoader from resolved Module / RDI?

        OK, this one looks easy to solve:

         

        if (item.resolve(controller))
              {
                 Module resolvedModule = item.getResolvedModule();
                 if (resolvedModule instanceof ClassLoaderPolicyModule)
                 {
                    ClassLoaderPolicyModule clpm = (ClassLoaderPolicyModule) resolvedModule;
                    DelegateLoader loader = clpm.getDelegateLoader(module, requirement);
        • 16. Re: Wildcard support in Dynamic-imports
          alesj
          1) How to add this new RequirementDependencyItem (RDI) to existing Module's requirementDependencies? -- package protected

          I guess this is all done as part of RDI::resolve, if actually resolved.

          And there is no need to add this to initial Module?

          • 17. Re: Wildcard support in Dynamic-imports
            alesj
            And there is no need to add this to initial Module?

            Moving WildcardDelegateLoader to same package as Module helps, but is it OK / valid?

             

            if (item.resolve(controller))
                  {
                     List<RequirementDependencyItem> items = module.getDependencies(); // should not be null, as this delegate was created from a requirement
                     items.add(item);
                     module.addIDependOn(item);
            • 18. Re: Wildcard support in Dynamic-imports
              warjort

              I said when I first committed jboss-classloading that is was a bad thing that RequirementDependencyItem was in the public spi.

              It shouldn't really be leaking the MC api through to the user but I couldn't think of an easy way to abstract it. So the spi is already a bit ugly. :-(

               

              One way to do it would be to make the class package private in spi and have a factory method on the Module to construct it,

              I haven't looked at whether this really works?

               

              package org.jboss.classloading.spi;

              /*package private*/ class WildcardDelegateLoader extends FilteredDelegateLoader

               

              and

               

              public class Module {

                  public DelegateLoader resolveWildcard(...)

                  {

                       WildcardDelegateLoader result = new WilcardDelegateLoader(...);

                       return result.resolve(...);

                  }

              }

               

              I'm sure you'll find a way to do it? :-)

              • 19. Re: Wildcard support in Dynamic-imports
                alesj
                public class Module {

                    public DelegateLoader resolveWildcard(...)

                    {

                         WildcardDelegateLoader result = new WilcardDelegateLoader(...);

                         return result.resolve(...); // HERE ??

                    }

                }

                I don't understand the idea behind resolve().

                 

                I thought we would simply create a single WildcardDelegateLoader for the whole wildcard requirement,

                which would then get hit for every not-yet-resolved class/resource lookup.

                Resulting in creating new DelegateLoader, and adding that to existing delegates -- before our wildcard "creator".

                 

                e.g.

                 

                class WildcardDelegateLoader extends FilteredDelegateLoader
                {
                   ...
                
                   protected DelegateLoader resolve(String pckg)
                   {
                      Requirement requirement = new PackageRequirement(pckg, range);
                      WildcardRequirementDependencyItem item = new WildcardRequirementDependencyItem(module, requirement, module.getClassLoaderState());
                      if (item.resolve(controller))
                      {
                         List<RequirementDependencyItem> items = module.getDependencies(); // should not be null, as this delegate was created from a requirement
                         items.add(item);
                         module.addIDependOn(item);
                         
                         Module resolvedModule = item.getResolvedModule();
                         if (resolvedModule instanceof ClassLoaderPolicyModule)
                         {
                            ClassLoaderPolicyModule clpm = (ClassLoaderPolicyModule) resolvedModule;
                            DelegateLoader loader = clpm.getDelegateLoader(module, requirement);
                            item.setLoader(loader);
                
                            ClassLoaderPolicy policy = getPolicy();
                            // TODO -- add new loader to policy's delegate
                
                            // pseudo-code -- ???
                            List<DelegateLoader> delegates = policy.getDelegates();
                            delegates.add(0, loader); // make sure it's before this wildcard delegate
                         }
                      }
                      return null;
                   }
                
                   @Override
                   protected Class<?> doLoadClass(String className)
                   {
                      DelegateLoader loader = resolve(ClassLoaderUtils.getClassPackageName(className));
                      return loader != null ? loader.loadClass(className) : null;
                   }
                

                 

                And I have no idea how to hack around this dynamic loader to policy's delegates addition.

                 

                Or I completely misunderstood your impl? :-)

                • 20. Re: Wildcard support in Dynamic-imports
                  alesj
                  And I have no idea how to hack around this dynamic loader to policy's delegates addition.

                  This would actually have to be done on CLInfo.

                   

                  e.g. 
                  ClassLoaderPolicy policy = getPolicy();
                  ClassLoaderInformation info = policy.getInformation(); // exposing this as protected in super, public in CLP
                  if (info != null)
                     info.addDelegate(loader); // new public method
                  

                   

                  Adding this hacks makes all previous wildcard tests pass. :-)

                  • 21. Re: Wildcard support in Dynamic-imports
                    warjort

                    Or I completely misunderstood your impl? :-)

                    I thought I was just showing your impl from the first post, but putting it in a factory method, I must have got it wrong if you don't understand it?

                     

                    On the delegate loaders, you can't just modify the delegates returned by the policy (you probably dont want to, it would just be something else

                    to tidyup later), its not used after the classloader gets constructed,

                    you want to update the ClassLoaderInformation - this is the optimized view of the policy for runtime.

                     

                    So you need a method (probably on ClassLoaderPolicy) like:

                     

                    void addExtraDelegate(DelegateLoader dl);

                    • 22. Re: Wildcard support in Dynamic-imports
                      warjort

                      Ales Justin wrote:

                       

                      And I have no idea how to hack around this dynamic loader to policy's delegates addition.

                      This would actually have to be done on CLInfo.

                       

                      e.g. 
                      ClassLoaderPolicy policy = getPolicy();
                      ClassLoaderInformation info = policy.getInformation(); // exposing this as protected in super, public in CLP
                      if (info != null)
                         info.addDelegate(loader); // new public method
                      

                       

                      Adding this hacks makes all previous wildcard tests pass. :-)

                       

                       

                      Don't expose the stuff from spi.base - its implementation detail.

                      Add proper helper methods to the stuff in spi.

                       

                      Its easy to make things public or protected, but then you'll have people poking around and breaking things.

                       

                      All you want to do is add a delegate at runtime, not expose the ugly guts of the classloader! :-)

                      • 23. Re: Wildcard support in Dynamic-imports
                        alesj
                        So you need a method (probably on ClassLoaderPolicy) like:

                         

                        void addExtraDelegate(DelegateLoader dl);

                        That's what I did -- the code is already commited. ;-)

                        But had to "protected" expose getInformation() in BaseClassLoaderPolicy so ClassLoaderPolicy can add the new delegate loader.

                        • 24. Re: Wildcard support in Dynamic-imports
                          alesj
                          But had to "protected" expose getInformation() in BaseClassLoaderPolicy so ClassLoaderPolicy can add the new delegate loader.

                          Eh, fixed this as well, only to expose the add/remove methods, but not the CLInfo itself.

                          • 25. Re: Wildcard support in Dynamic-imports
                            warjort

                            Ales Justin wrote:

                             

                            So you need a method (probably on ClassLoaderPolicy) like:

                             

                            void addExtraDelegate(DelegateLoader dl);

                            That's what I did -- the code is already commited. ;-)

                            But had to "protected" expose getInformation() in BaseClassLoaderPolicy so ClassLoaderPolicy can add the new delegate loader.

                            No, just add it as a public method to BaseClassLoaderPolicy, it will get inherited into ClassLoaderPolicy.

                            Obviously the spi.base.* stuff has to have some public/protected methods otherwise it couldn't be used, but keep

                            whats exposed down to a minimum. :-)

                            • 26. Re: Wildcard support in Dynamic-imports
                              alesj
                              Don't expose the stuff from spi.base - its implementation detail.

                              Add proper helper methods to the stuff in spi.

                               

                              Its easy to make things public or protected, but then you'll have people poking around and breaking things.

                               

                              All you want to do is add a delegate at runtime, not expose the ugly guts of the classloader! :-)

                              Done. ;-)

                              * http://anonsvn.jboss.org/repos/jbossas/projects/jboss-cl/trunk/classloading/src/main/java/org/jboss/classloading/spi/dependency/WildcardDelegateLoader.java

                              • 27. Re: Wildcard support in Dynamic-imports
                                alesj
                                No, just add it as a public method to BaseClassLoaderPolicy, it will get inherited into ClassLoaderPolicy.

                                Obviously the spi.base.* stuff has to have some public/protected methods otherwise it couldn't be used, but keep

                                whats exposed down to a minimum. :-)

                                I hack stuff faster than I think, but then I fix it before you can actually reply to my stupid code. :-)

                                 

                                I actually made the add/remove methods protected in BaseCLP and public in CLP which delegate to BaseCLP methods.

                                But if you prefer them public in BaseCLP that can be arranged. ;-)

                                • 28. Re: Wildcard support in Dynamic-imports
                                  alesj
                                  you want to update the ClassLoaderInformation - this is the optimized view of the policy for runtime.

                                  void addExtraDelegate(DelegateLoader dl);

                                  Once we add new delegate loaders the caching and blacklisting setting can change.

                                  e.g. adding non-caching delegate loader to existing all-caching delegate loaders

                                   

                                  Does it make sense to track this and apply accordingly?

                                  e.g. nullify cache if we add-non caching delegate loader, and restore to previous state once removed

                                  Or should we simply ignore any caching and blacklisting if extra delegate loader is added?

                                   

                                  I'll try to go with the tracking approach, and see how complicated it is.

                                  • 29. Re: Wildcard support in Dynamic-imports
                                    warjort

                                    If you've got wildcards for dynamic imports it can't blacklist unless the package in question doesn't match the wildcard.

                                    The package could suddenly appear, and even then its not complete because there may be other packages yet to appear that match it.