Ales Justin wrote:
> We've always had a flat domain. JBoss AS 4.x boots in 10
seconds.
Sure.
But how much smaller is 4.x?
Not much smaller. I think my profiling has shown that it is the
MC/VDF/VFS that is the problem (as compared to JBoss 4), not the
deployed components. People seem to forget that AS 5 is not much
different feature wise than what we had in 4.x.
Plus resource lookup doesn't run on top of VFS ...
Yeah, but doesn't deployment require the VFS for finding subdeployments?
And thus...doesn't the VFS run for each and every deployed
JAR/Directory (and subjar/directory)?
VFS use should be banned from AS (not from application deployment
though). Its slow and will probably remain slow as you're scanning and
creating metadata for each and every file within each jar. It should be
replaced with a structure xml file describing the structure (don't we
already have this capability?) of the directory or jar as well as an
annotation database file.
> Instead of a jboss-classloading.xml, why not reading the
manifest? Or
> is somebody working on that?
This is something we're definitely planning.
I once discussed it with Scott what we should support.
Afair, we agreed on supporting both.
But as you can see from SS+OSGi_repo story, this is not as trivial as it
looks.
Once we have this fully in place, DML's modularization, etc,
we should make sure we can re-use stuff from SS's repo.
There's already a osgi maven bundle plugin. Why not use it?
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
Why not use that to generate exported packages? Just tried it out.
Pretty cool.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com