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

[adrian@jboss.org]

"scott.stark at jboss.org" wrote : 
  | First, does module name equate to the osgi bundle symbolic name? We would also need additional policy information that equates to the Require-Bundle header parameters. 
  | 

As I understand it, yes. Although I allow multiple names, i.e.
multiple module capabilities/aliases.
I'm using a "context name" internally, which you can either specifiy explicitly
or it will generate one for you as "name:version"

anonymous wrote : 
  | "adrian at jboss.org" wrote : 
  |   | 1) Is the above "Note" about mutual exclusion of exportAll and listing
  |   | capabilities correct? If not, it could get very messy trying to merge them. ;-)
  |   | 
  | I guess, I can't see why one would want to use both syntaxes.
  | 

I've erronously tried to do so in the tests which is why I thought about implementing it. :-)

anonymous wrote : 
  | "adrian at jboss.org" wrote : 
  |   | 4) Should I create an included export filter?
  |   | This would mean all classes are in the classloader, but only
  |   | the listed packages are exported.
  |   | While this might seem obvious, it is effectively the same as listing the
  |   | packages in the capabilities and therefore redundant.
  |   | It would also mean that "exportAll" doesn't really have that meaning anymore,
  |   | instead a better name would be something like "autoDiscoverPackages". :-)
  |   | 
  | I don't see the difference between this and the export-all="ALL" included="..." notion. What is the difference?
  | 

This would be exportAll="ALL" includedExport="p1,p2,p3".

The "included" by itself also controls what you can see of yourself in the module,
an included export or the package capabilities control what others can see,
i.e. your exports.

NOTE: included and excluded are still valid with explicit capabilities
since they only act as an additional filter that applies to both
you and others rather than as a potentially conflicting one. ;-)

anonymous wrote : 
  | "adrian at jboss.org" wrote : 
  |   | a) Do you think we should "fixup" the capabilities, i.e.
  |   | missing module capabilities, missing package versions
  |   | or should we just do what the user says?
  |   | 
  | What would the version be fixed up to? In terms of modules, unless its mapped to something usable like the deployment name, how would the fixed up name be usable?
  | 

Possible fix ups would be:

* Even if capabilities are explicit always add a module capability from the name
given in the top level element. e.g. for deployments it could be the deployment
name.

* If there is a version in the top level element then add that to any capability
that would otherwise have 0.0.0 as its version (the default, unspecified version).

anonymous wrote : 
  | "adrian at jboss.org" wrote : 
  |   | b) Is it worth trying to go through the "hard problem" of merging
  |   | the simple but not very explicit exportAll processing with explicit capabilities?
  | I think we need to go through the resolution process when there are amiguities to see if there are defaults we should fixup to minimize problems.
  | 

The issues would be around contradictory specifications, e.g.

  | <classloader exportAll="ALL" excludeExport="p1">
  | <capability>
  |    <package name="p1"/>
  | ...
  | 

So is p1 in the exports or not? ;-)

There's probably other more complicated examples.
Especially since I didn't mention that although these filters are shown
as lists of packages, I'm potentially allowing any ClassFilter and wildcard
capabilities so I don't necessarily know exactly what they mean,
although I do know if the Capability implements ExportPackages
which is part of the way.

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

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