Just did some profiling of determineAllPackages in a simple isolated
test with jacorb.jar (4.58M)
Test took 747ms.
51% was within initEntries (ZipEntryContext) (VFS 2.2.0Alpha1)
11.3% was in VFS.getVFS()
7.8% was in VFS.getRoot()
9% of time was used in determineAllPackages.
The rest was just org.jboss.test initialization.
So, it may not be determineAllPackages itself, but the initialization of
the VFS.
Beyond optimizing VFS, it doesn't make much sense, IMO, to use the VFS
at all for jboss system, subsystem, component, jars. They don't need to
be scanned for anything as all information/metadata can be
pre-initialized and stored within the jar in a config file.
Bill Burke wrote:
David M. Lloyd wrote:
> On 01/04/2010 07:18 AM, Ales Justin wrote:
>>> Its all AOP,
>> This one is taken care by Kabir.
>>
>>> Classloading (package names),
>> Perhaps Bill you could have a go at this?
>>
>> Basically the solution is trivial, but it's an integration pita.
>> What we need is an explicit packages export; aka jboss-classloading.xml
>> with capabilities.
> Why packages? Why not export/import by module? Also, the
> jboss-classloading.xml is only a part of a performant solution. Before we
> consider going to a fully modularized design, we also need to consider a
> way to implement an O(1) module loading system, so that modules are only
> loaded on-demand and any module which is not used is never loaded.
> Otherwise, we'll never be able to scale a "modularized" AS.
>
I think these on-demand and modularization features should be put on
hold until you get a modern app-server that is consumable by developers.
I assure you that boot speed and usability (embedability/unit testing)
are 99% more important to developers than on-demand/modularization.
I know we can get development-mode AS booting in < 5 secs (web, ejb, tx
jca, jms, ws, rs).
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com