Mailing-List: contact issues-help@shale.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@shale.apache.org
Message-ID: <4415380.1159692135553.JavaMail.root@brutus>
Date: Sun, 1 Oct 2006 01:42:15 -0700 (PDT)
From: "Mario Ivankovits (JIRA)" <jira@apache.org>
To: issues@shale.apache.org
Subject: [jira] Updated: (SHALE-301) scan configures packages or jar files
  only
In-Reply-To: <5703735.1159558095417.JavaMail.root@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

     [ 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