[jboss-dev] Scanning jars for package capabilities

[Scott Stark]

There was a discussion of creating our own index format based on a pure 
java zip file implementation that would allow for building metadata 
information beyond just package names;

- annotations
- packages
- classes
- nested jars

This would just be input into the vfs layer, and separate from the 
jboss-classloading.xml which would describe which packages would be visible.

David M. Lloyd wrote:
> What about simply not doing that?  In other words, don't advertise 
> capabilities unless they are expressly defined in a 
> jboss-classloading.xml... is this an option?
>
> Also - it may be worth seeing if specifying jboss-classloading.xml 
> disables this scanning action.
>
> - DML
>
> On 06/18/2009 04:30 PM, Kabir Khan wrote:
>> "jar i" looks like it will also include the packages from the jars in 
>> the Class-Path attribute?
>>
>>  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