1 2 3 Previous Next 32 Replies Latest reply: Jun 14, 2010 8:13 AM by Ales Justin Go to original post RSS
  • 15. Re: Wildcard support in Dynamic-imports
    Ales Justin Master
    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
    Ales Justin Master
    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
    Ales Justin Master
    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
    Adrian Brock Newbie

    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
    Ales Justin Master
    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
    Ales Justin Master
    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
    Adrian Brock Newbie

    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
    Adrian Brock Newbie

    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
    Ales Justin Master
    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
    Ales Justin Master
    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
    Adrian Brock Newbie

    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
    Ales Justin Master
    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
    Ales Justin Master
    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
    Ales Justin Master
    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
    Adrian Brock Newbie

    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.