[ http://issues.apache.org/struts/browse/SHALE-301?page=all ]
Mario Ivankovits updated SHALE-301:
-----------------------------------
Attachment: DumpScanPackages.diff
A utility class which helps to determine packages with shale-tiger annotated
classes within.
You simply start this tool using:
java -XX:MaxPermSize=99m -cp
shale-tiger.jar:WEB-INF/classes:WEB-INF/lib/dependency.jar:....
org.apache.shale.tiger.utils.DumpScanPackages
You simply have to add classes to check to the classpath.
The tool will produce plenty of warnings due to an incomplete classpath (e.g.
if you left out the servlet jar etc), you can add those jars from your
container too, or simply ignore it.
In case of an OutOfMemory exception simply increase the MaxPermSize parameter.
At the end the tool will print out stuff like:
Propsed org.apache.shale.tiger.SCAN_PACKAGES configuration:
<context-param>
<param-name>org.apache.shale.tiger.SCAN_PACKAGES</param-name>
<param-value>com.ops.Contact.backings<param-value>
</context-param>
You can copy/paste this proposal in your web.xml then.
> scan configures packages or jar files only
> -------------------------------------------
>
> Key: SHALE-301
> URL: http://issues.apache.org/struts/browse/SHALE-301
> Project: Shale
> Issue Type: New Feature
> Components: Tiger
> Reporter: Mario Ivankovits
> Attachments: configurable_scan_packages.diff, DumpScanPackages.diff,
> DumpScanPackages.java
>
>
> Attached you will find a patch which allows to configure which packages or
> jar files shale-tiger should scan during startup.
> The idea behind this patch is to improve the startup times of shale-tiger,
> though, this requires to have a good insight when used with 3rd party
> libraries. But the faster startup time one might get is especially during
> development worth it.
> If the context configuration parameter is missing, the old scanning behaviour
> will be used.
> A example for the configuration parameter:
> <context-param>
> <param-name>org.apache.shale.tiger.SCAN_PACKAGES</param-name>
>
> <param-value>com.ops.Contact.backings,com.ops.OPSJ.jsflib,shale-tiger-1.0.4-dev.jar</param-value>
> </context-param>
> This example means:
> * Scan all classes in "com.ops.Contact.backings" (and its children)
> * Scan all classes in "com.ops.OPSJ.jsflib" (and its children)
> * Scann all classes in "shale-tiger-1.0.4-dev.jar"
> Using the above configuration speedup the startup from shale-tiger from 4.5
> seconds to 0.5 seconds (for our application in development mode with 1461
> classes in WEB-INF/classes and 91 dependencies in WEB-iNF/lib)
> old behaviour:
> 2006-09-29 21:08:08,286 INFO [main] faces.LifecycleListener2 - Starting up
> Shale Tiger extensions
> 2006-09-29 21:08:12,847 INFO [main] faces.LifecycleListener2 - Startup of
> Shale Tiger extensions is complete
> new behaviour:
> 2006-09-29 21:09:32,018 INFO [main] faces.LifecycleListener2 - Starting up
> Shale Tiger extensions
> 2006-09-29 21:09:32,506 INFO [main] faces.LifecycleListener2 - Startup of
> Shale Tiger extensions is complete
> The patch is meant as a start for a discussion, once we found that this
> should go into the codebase I'll try to figure out how to create a test case
> and a better documentation for it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
