[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);

[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?

[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);

[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? :-)

[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? :-)

[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. :-)

[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);

[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! :-)

[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.

[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.

[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. :-)

[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

[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. ;-)

[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.

[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.