[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [jboss-dev] Scanning jars for package capabilities Scott Stark Thu Jun 18 23:00:20 2009

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.


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?


jboss-development mailing list