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