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

[adrian@jboss.org]

I'd like to here people's opinions on the following issues
with the new OSGi classloading metadata.

First some explanation.

The classloading metadata looks like this:

  | <classloading xmlns="urn:jboss:classloading:1.0">
  | 
  | <!-- capabilities are classloading exports -->
  |    <capabilities>
  | <!-- This deployment can be referenced by either of these two module names -->
  |       <module name="export2" version="2.0.0"/>
  |       <module name="export1" version="1.0.0"/>
  | <!-- It exports these packages with the given versions -->
  |       <package name="export2" version="2.0.0"/>
  |       <package name="export1" version="1.0.0"/>
  |    </capabilities>
  | <!-- requirements are classloading imports -->
  |    <requirements>
  | <!-- It needs to import the following modules -->
  |       <module name="import2" from="2.0.0"/>
  |       <module name="import1" from="1.0.0"/>
  | <!-- and packages -->
  |       <package name="import2" from="2.0.0"/>
  |       <package name="import1" from="1.0.0"/>
  |    </requirements>
  | </classloading>
  | 

OFF-TOPIC: The above is the deployment metadata, i.e. META-INF/jboss-classloading.xml where the "classpath" is already known
from the deployment structure.
There's a similar one for use in a -beans.xml, except
in a different namespace because there you have to specify the
roots as well, e.g.

  | <deployment>
  |    <classloader><inject bean='MyClassLoader"/></classLoader>
  | 
  |    <classloader name="MyClassLoader" xmlns="urn:jboss:classloading:1.0">
  |        <!-- similar to above -->
  | 
  |        <root>${jboss.lib.url}/some.jar</root>
  |        <root>${jboss.lib.url}/another.jar</root>
  |    </classloader>
  | 
  |    <!-- beans here -->
  | </deployment>
  | 

For ease-of-use and "backwards compatibity" there are some shorthands.

Module name and version shorthand which automatically
creates a single module capability.

  | <classloading name="test" version="1.0.0" xmlns="urn:jboss:classloading:1.0"/>
  | 

Exporting all packages

  | <classloading name="test" version="1.0.0" export-all="ALL"
  | xmlns="urn:jboss:classloading:1.0"/>
  | 


Exporting all packages with an inclusion filter
i.e. only the packages listed are part of the classloader and exported

  | <classloading name="test" version="1.0.0" export-all="ALL" included="org.jboss.package1,org.jboss.package2"
  | xmlns="urn:jboss:classloading:1.0"/>
  | 

Exporting all packages with an exclusion filter
i.e. all packages are included in the classloader and exported except
the ones listed

  | <classloading name="test" version="1.0.0" export-all="ALL" excluded="org.jboss.package1,org.jboss.package2"
  | xmlns="urn:jboss:classloading:1.0"/>
  | 

Exporting all packages with an excluded export filter
i.e. all packages are included in the classloader but the given classes
are not exported

  | <classloading name="test" version="1.0.0" export-all="ALL" excludedExport="org.jboss.package1,org.jboss.package2"
  | xmlns="urn:jboss:classloading:1.0"/>
  | 

In the above examples with filters, the packages are automatically
created as "capabilities" with the same version as the module.

Note: the exportAll and explicitly listing capabilities are mutually exclusive.
ExportALL and its related filters are ignored if you list capabilities explicity

NOW FOR THE QUESTIONS.

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

2) In the filter case, the packages automatically get the version of the module,
but this doesn't happen for listing capabilities explicitly


  | <classloading xmlns="urn:jboss:classloading:1.0">
  |    <capabilities>
  |       <module name="export1" version="1.0.0"/>
  |       <package name="export2"/>
  | 
The package export2 has version 0.0.0 if you are explicit.

3) Similar to (2) there is no fixup on the explicit capabilities.


  | <classloading xmlns="urn:jboss:classloading:1.0">
  |    <capabilities>
  |       <package name="export2"/>
  | 
This deployment has NO module capability.

4) Should I create and included export filter?
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". :-)

SUMMARY

The above questions boil down to two issues.

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?

b) Is it worth trying to go through the "hard problem" of merging
the simple but not very explicit exportAll processing with explicit capabilities?

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

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