Hi Craig!
1) Speedup of startup
... because it expects the developer to have a fairly complete
understanding of all the classes in every jar, even if you got it from a
third party.
oh yes, right you are
So the syntax of the configuration should be somehow different:
On 9/28/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi Craig!
1) Speedup of startup
... because it expects the developer to have a fairly complete
understanding of all the classes in every jar, even if you got it from a
third party.
oh yes, right you are
So the syntax of the
Hi Craig!
1) Speedup of startup
See my response on your JIRA issue ...
The JIRA issue and this topic are two completely different things.
Please take a look at the patch and you'll see.
if the developer *does* include this
context init parameter, then it seem that we would have to analyze
Hi Craig!
I wont leave this mailing list ;-)
For the speedup thing (with a new context parameter) I'll try to
implement my thoughts in LifecycleListener2 and create a simple benchmark.
Then we will see if its worth it.
Ciao,
Mario
Hi!
For the speedup thing (with a new context parameter) I'll try to
implement my thoughts in LifecycleListener2 and create a simple benchmark.
Then we will see if its worth it.
I created https://issues.apache.org/struts/browse/SHALE-301 with a first
try to speedup startup times, so
On 9/28/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
I would like to discuss two things which come in my mind during trying
out shale-tiger:
1) Speedup of startup
While shale-tiger already tries its best to parse only jars with
specific markers I think we can further speedup the startup
