
|
If you were logged in you would be able to see more operations.
|
|
|
|
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.
|
|
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. |
Show » |
|