[Prev] Thread [Next] |
[Prev] Date [Next]
Re: [jboss-dev] Scanning jars for package capabilities
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;
- 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
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
I was thinking whether we could reduce this time by having a
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