JIT bridge loading?

[Michael Turyn <MT...@nexaweb.com>]

For awhile I've been annoyed that we pre-load all bridges mapped in the
plugin file (...xap/taghandling/plugin.xml) regardless of how many we're
using.  Now, the bridge class objects aren't so large, but it adds to
the initial request load....

I've written a fix for this---it's fairly simple, just doesn't do a
require() when we read the tag mapping in PluginRegistryImpl, but does
one in PluginDocumentHandler when we actually need the bridge.  It works
simply and well.

However, this means that some code that works today might not if it
needs a bridge class (say, for a constant or a static method) but has no
explicit require() for it---up until now, it would have got by because
all the bridge classes will have been pre-loaded.  I don't think this is
a major problem, but it could arise.  (On the plus side, if all the
strictly needed require() statements are in the class source,
dependencies are clearer.)

So: are there any objections to my making the loading change?  I'll give
it a couple of days.




(I'm not doing the equivalent for lifecycle objects---the Mco,
Datasource, Binding, and Iterator containers---because this code is less
well established, and in any event there are only four of them, and the
list is not likely to grow much.)

RE: JIT bridge loading?

[James Margaris <jm...@nexaweb.com>]

Sounds good to me. If a bridge doesn't have the right require() that is
something we need to fix anyway.

James Margaris 

-----Original Message-----
From: Michael Turyn [mailto:MTuryn@nexaweb.com] 
Sent: Tuesday, October 17, 2006 3:36 PM
To: xap-dev@incubator.apache.org
Subject: JIT bridge loading?

For awhile I've been annoyed that we pre-load all bridges mapped in the
plugin file (...xap/taghandling/plugin.xml) regardless of how many we're
using.  Now, the bridge class objects aren't so large, but it adds to
the initial request load....

I've written a fix for this---it's fairly simple, just doesn't do a
require() when we read the tag mapping in PluginRegistryImpl, but does
one in PluginDocumentHandler when we actually need the bridge.  It works
simply and well.

However, this means that some code that works today might not if it
needs a bridge class (say, for a constant or a static method) but has no
explicit require() for it---up until now, it would have got by because
all the bridge classes will have been pre-loaded.  I don't think this is
a major problem, but it could arise.  (On the plus side, if all the
strictly needed require() statements are in the class source,
dependencies are clearer.)

So: are there any objections to my making the loading change?  I'll give
it a couple of days.




(I'm not doing the equivalent for lifecycle objects---the Mco,
Datasource, Binding, and Iterator containers---because this code is less
well established, and in any event there are only four of them, and the
list is not likely to grow much.)