[jboss-dev] Scanning jars for package capabilities

[Jaikiran Pai]

Kabir Khan wrote:
> "jar i" looks like it will also include the packages from the jars in 
> the Class-Path attribute?
That's correct. But most (almost all?) JBoss specific jar files do not 
have Class-Path attribute in their MANIFEST.MF.

I thought about this, a bit more yesterday and also saw the replies to 
this thread about jboss-classloading.xml. This wiki 
http://www.jboss.org/community/wiki/JBoss5custommetadatafiles does not 
have a complete picture/example of jboss-classloading.xml, but i guess 
instead of saying "EXPORT_ALL" (which triggers the scanning of jar for 
packages) we could probably configure each deployer/deployment to have 
this file with a set of "includes"/"capabilities" and explicitly list 
the packages available? I still am not sure if that's going to work or 
if it's the expected usage, but atleast instead of creating and parsing 
the INDEX.LIST, we could probably rely on the existing functionality 
exposed by jboss-classloading.xml.

Thoughts?

-Jaikiran

>
> From http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/jar.html#i :
>
> "Generate index information for the specified jarfile and its 
> dependent jar files. For example:
> jar i foo.jar
> would generate an INDEX.LIST file in foo.jar which contains location 
> information for each package in foo.jar and all the jar files 
> specified in the Class-Path attribute of foo.jar. See the index example."
>
> On 18 Jun 2009, at 13:58, Jaikiran Pai wrote:
>
>> Resending with a zipped snapshot. Did not realize that the earlier 
>> html attachment was large.
>>
>> I was just looking at the profiler output against AS trunk today and 
>> noticed that considerable amount of time is being spent in the 
>> AbstractClassLoaderDeployer.deploy which internally creates a 
>> classloader for deployers/deployments. Internally a 
>> VFSDeploymentClassLoaderPolicyModule goes on to determine the 
>> "capabilities" of each module. This include traversing the jar 
>> file(s) to find out what "packages" are contained. Attached is the 
>> profiler snapshot.
>>
>> I was thinking whether we could reduce this time by having a 
>> INDEX.LIST file 
>> http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/jar.html#i (or 
>> something similar) which would list the packages available/exposed in 
>> a jar file (sample generated file attached for 
>> jboss-common-core.jar). We cannot enforce this on end user 
>> deployments but atleast the jars shipped by the server probably could 
>> include this? This probably will have its own issues in terms of 
>> maintaining that list so that it does not become outdated. We could 
>> use the jar -i command to create the index files everytime a jar is 
>> generated, but again needs to be followed by each project.
>>
>> Is this something that we should be looking into? Or are there any 
>> better ways of dealing with this?
>>
>> -Jaikiran
>> <AS trunk snapshot.zip>_______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>