[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: ClassLoadingMetaData ease-of-use

[adrian@jboss.org]

"scott.stark at jboss.org" wrote : "adrian at jboss.org" wrote : 
  |   | I'll do them as elements so you can properly customize it.
  |   | With xml wildcards, etc. to define your own.
  |   | 
  | Ok, but then if the attribute form still exists, won't it just be an alias for the most common element construct? To get back to the original question, it seems both included/excluded attributes and include/capability elements make sense. The attributes being shorthand for common element forms.
  | 
  | In the case where attributes/elements overlap, we have to consider understanding the filter type, 
  | 

Well actually I coded it as running both filters if you specify both,
using a CombiningClassFilter. i.e. it will apply both the package list and
any custom filter you specify.

ClassLoadingMetaData

  | 
  |    /**
  |     * Get a filter for the included packages
  |     * 
  |     * @return the included packages
  |     */
  |    public ClassFilter getIncluded()
  |    {
  |       ClassFilter packageFilter = null;
  |       if (includedPackages != null)
  |          packageFilter = PackageClassFilter.createPackageClassFilterFromString(includedPackages);
  |       
  |       if (packageFilter == null)
  |          return included;
  |       if (included == null)
  |          return packageFilter;
  |       return CombiningClassFilter.create(true, packageFilter, included);
  |    }
  | 

anonymous wrote : 
  | even if only in the management interface to help diagnose conflicts like declaring a p1 capability when p1 was not made visible to the class loader itself. For that we would need access to the raw packages, local packages, and exported packages.
  | 

If you declare that you export a package and it doesn't exist, then that's your fault. ;-)

But this only comes up with the explicit package capabilties. The filters are not
absolute declarations, they are, well, filters on what it finds when scanning
the "file system".

I suppose I could validate the capabilities that say they "ExportPackages"
by running the ExportALL processing even if you explicitly list the package capabilities,
but I'm not sure it really buys much?
You'll still get a ClassNotFoundException on javax.jms.Queue
if you export the package, include it in your filesystem but don't have that class. ;-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131464#4131464

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131464