[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: ClassLoadingMetaData ease-of-use
"scott.stark(a)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(a)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(a)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(a)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(a)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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...