On 02/11/2010 10:24 AM, Rémy Maucherat wrote:
On Thu, Feb 11, 2010 at 4:46 PM, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
> Is some kind of blunt filtering mechanism useful? A la what we do with
> JBossCustomDeployDUFilter and GenScanDeployer beans in
> metadata-deployer-jboss-beans.xml.
I heard there was something, but I don't know it. And it's not
metadata-complete (it will only disable select Servlet 3.0
annotations).
> (Unverified assumption: WARAnnotationMetaDataDeployer doesn't need to
> process admin-console.war)
Most likely it does not.
But it's pretty much pointless, we use a nasty SCI from JSF (which
would also need a flag to avoid scanning the war).
So I think we might be needing a number of flags added to
jboss-web.xml (disable-annotations - if needed - and
disable-handlestypes), but I'd argue we should target that for M3. M2
boots pretty fast so we have an improvement already for the most
visible item.
As a quick way to experiment, I changed deploy() for
WARAnnotationMetaDataDeployer and ServletContainerInitializerDeployer to add
if ("admin-console.war".equals(unit.getSimpleName()))
return;
That cut the boot time of "default" with on-demand disabled from 38s to
30s. I get 22s with on-demand enabled.
I agree that the M2 boot improvement is already enough. Only reason to
think about any 1) quick 2) simple 3) safe stuff for M2 is to cut the
time it takes to serve the first admin-console request, which for me is
a) 12 secs before I get any response at all (i.e. deployment time)
b) 5 secs looking at the "Redirecting to..." page until login screen
comes up (i.e. mostly ServletContextListener stuff)
c) 5 secs to get response after submitting login form (console initially
processes managed objects)
a) is the worst part since there's no feedback.
Still, I'm quite OK with leaving this alone. TBH the only 1) quick 2)
simple 3) safe stuff for M2" is the hack above, which is pretty lame.
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat