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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development