You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@shale.apache.org by "Mario Ivankovits (JIRA)" <ji...@apache.org> on 2006/09/29 21:28:15 UTC
[jira] Created: (SHALE-301) scan configures packages or jar files
only
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
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
[jira] Commented: (SHALE-301) scan configures packages or jar files
only
Posted by "Mario Ivankovits (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-301?page=comments#action_38322 ]
Mario Ivankovits commented on SHALE-301:
----------------------------------------
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?
> 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
[jira] Commented: (SHALE-301) scan configures packages or jar files
only
Posted by "Mario Ivankovits (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-301?page=comments#action_38315 ]
Mario Ivankovits commented on SHALE-301:
----------------------------------------
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.
> 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
>
>
> 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
[jira] Commented: (SHALE-301) scan configures packages or jar files
only
Posted by "Craig McClanahan (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-301?page=comments#action_38440 ]
Craig McClanahan commented on SHALE-301:
----------------------------------------
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?
> 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
[jira] Updated: (SHALE-301) scan configures packages or jar files
only
Posted by "Mario Ivankovits (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-301?page=all ]
Mario Ivankovits updated SHALE-301:
-----------------------------------
Attachment: configurable_scan_packages.diff
> 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
>
>
> 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
[jira] Commented: (SHALE-301) scan configures packages or jar files
only
Posted by "Craig McClanahan (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-301?page=comments#action_38323 ]
Craig McClanahan commented on SHALE-301:
----------------------------------------
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.
> 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
[jira] Resolved: (SHALE-301) scan configures packages or jar files
only
Posted by "Craig McClanahan (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-301?page=all ]
Craig McClanahan resolved SHALE-301.
------------------------------------
Fix Version/s: 1.0.4-SNAPSHOT
Resolution: Fixed
Fixed in nightly build 20061020, and will also be included in 1.0.4. Thanks for the patch!
> 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
> Assigned To: Craig McClanahan
> Fix For: 1.0.4-SNAPSHOT
>
> 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
[jira] Assigned: (SHALE-301) scan configures packages or jar files
only
Posted by "Craig McClanahan (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-301?page=all ]
Craig McClanahan reassigned SHALE-301:
--------------------------------------
Assignee: Craig McClanahan
> 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
> Assigned To: Craig McClanahan
> 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
[jira] Commented: (SHALE-301) scan configures packages or jar files
only
Posted by "Mario Ivankovits (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-301?page=comments#action_38441 ]
Mario Ivankovits commented on SHALE-301:
----------------------------------------
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.
> 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
[jira] Updated: (SHALE-301) scan configures packages or jar files
only
Posted by "Mario Ivankovits (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-301?page=all ]
Mario Ivankovits updated SHALE-301:
-----------------------------------
Attachment: DumpScanPackages.java
Please ignore the DumpScanPackages.diff, there the new file in question is missing.
I've directly added DumpScanPackages.java now.
> 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
[jira] Updated: (SHALE-301) scan configures packages or jar files
only
Posted by "Mario Ivankovits (JIRA)" <ji...@apache.org>.
[ 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