[jboss-dev] Scanning jars for package capabilities

[David M. Lloyd]

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
>> <AS trunk snapshot.zip>_______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> 
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development