Re: [JBoss-dev] Looks like we need a big optimization in the ULR

[Howard M. L. S. <hl...@at...>]

I've noticed that Tapestry applications deployed into JBoss 3.0.0 have
miserable initial load times.  Tapestry is another very heavy user of
java.beans.Introspector, but it caches the information it collects, so
things quickly return to normal speed (revisting an already loaded page is
normal speed).

----- Original Message -----
From: "Scott M Stark" <Sco...@jb...>
To: <jbo...@li...>
Sent: Friday, June 28, 2002 12:28 PM
Subject: [JBoss-dev] Looks like we need a big optimization in the ULR


> I'm looking at a bug report reguarding how slow a simple
> webworks app when embedded in JBoss vs standalone
> tomcat is showing that we really need a seperate binary
> tree index by package elements. Webworks is a big PropertyEditor
> user and when you invoke PropertyEditor.findEditor(Class type)
> this spins through the package prefixes defined in the editor
> search path looking for a class matching the pattern
> package_prefix + '.' SimpleClassName + "Editor"
>
> The web container is delegating the call the its parent which is
> a UCL and this ultimately spins through all UCLs in the repository
> even though there is zero chance of a match due to the fact that
> the editors are in the webworks jar in the war.
>
> If we had a binary tree keyed by the elements of the package
> namespace we could quickly fail the search as soon as we determine
> we don't have any classes from the webwork.* namespace. I think
> this would also help the startup times which are much slower in 3.0.
>
> xxxxxxxxxxxxxxxxxxxxxxxx
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
> xxxxxxxxxxxxxxxxxxxxxxxx
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Caffeinated soap. No kidding.
> http://thinkgeek.com/sf
> _______________________________________________
> Jboss-development mailing list
> Jbo...@li...
> https://lists.sourceforge.net/lists/listinfo/jboss-development