scan configures packages or jar files only

• Key: SHALE-301
• Type: New Feature
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Craig McClanahan
• Reporter: Mario Ivankovits
• Component/s: Tiger
• Fix Version/s: 1.0.4

Description

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.

Comments

[Mario Ivankovits]

The next idea comming into my mind is a tool which will scan the classpath and prints all packages containing classes with a shale-tiger annotation.

In case of 3rd party libraries any developer should then be able to figure out the SCAN_PACKAGES configuration string easily.

[Mario Ivankovits]

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.

[Mario Ivankovits]

Please ignore the DumpScanPackages.diff, there the new file in question is missing.
I've directly added DumpScanPackages.java now.

[Mario Ivankovits]

Sometimes I have up to 12-15 seconds of startup time of shale-tiger - looks like it depends on the load of the machine, whereas when using the new scanning stuff startup is always under a second.

It would be great if we could add this to the codebase.
Any objections, anything I can do better to make this happen?

[Craig McClanahan]

I will try to review this as soon as I can ... but I'm currently at the AjaxWorld conference in Santa Clara. One good thing about ApacheCon next week. I'll be able to *focus* on Shale and get a lot of stuff done.

[Craig McClanahan]

Mario, I'm ready to look at this in depth in the next couple of days. Exactly which of the attachments should I pay attention to now?

[Mario Ivankovits]

Hi!

Great, thanks!


The files to pay attention to are:

* configurable_scan_packages.diff - this is the core of the additional startup scanning stuff

* DumpScanPackages.java - is just a helper to print out a proposal for the web.xml configuration by scanning the whole classpath, its optional, you do not need to add it if you just would like to add the startup scanning stuff.

[Craig McClanahan]

Fixed in nightly build 20061020, and will also be included in 1.0.4. Thanks for the patch!