avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Sutic <leosu...@apache.org>
Subject Re: Attributes Proof of Concept
Date Wed, 13 Aug 2003 12:04:29 GMT
OK, let's squibble!

> First of all you assume that it is a server!  Haven't I seen Desktop
> being built on top of Avalon?

This is the Apache Server Framework - I *should* be assuming server use
and optimize for it. Desktop use is secondary.

> Secondly, you assume that all servers are OK with a long start-up. I,
> instance, don't tolerate that my servers take 30s to get back up. It's
> wasting my time.

In the servers that have acceptable startup times, how much of the startup
time is done loading classes?

> Thirdly, you assume that all the jars only contains classes that are
> used. I beg to differ. As a stupid example, rt.jar, is far from loaded
> when I create a small app.

rt.jar is loaded by the bootstrap classloader and is thus inaccessible and
will never be scanned. Any class loaded by it will have its
getClass().getClassLoader() == null, so it is unreachable. (Think about
it, java.lang.ClassLoader is in rt.jar. Who loads it?)

> With proper SoII, I foresee a large amount of
> implementation classes that are not loaded.

Point taken.

> Fourthly, you assume that a couple of hundred classes is fine. Take a
> concrete example, Cocoon, how many classes are in 50+ jar files?? I
> haven't checked, but...  And I believe Cocoon is not the most extreme
> case, especially since there are people (like me) who embedd the whole
> Cocoon as a subsystem into a larger application.

My assumption isn't that a couple of hundred classes is fine. Suppose
Cocoon consists of a hundred bazillion classes, for argument's sake. Does
Cocoon have an acceptable startup time? I assume yes. OK, how much of that
time is spent loading classes? Double that time and add it to the startup
time. Still acceptable?

OK, how about this: Instead of scanning *every* class we can get our hands
on, we limit this process to scanning bundles. I.e. if Avalon gets an
equivalent of the .war file, we will only scan such files. This means that
we limit this to the jars that have a potential to contain Avalon

Suppose we have a directory structure for jars like this:

   lib/  (not scanned)
    +-- ext (not scanned)
    +-- endorsed (not scanned)
    +-- avalon (scanned)

The difference between this and some kind of index file si that I think it
is easier to just drop a jar in a given directory, than it is to *always*
make sure your run a specific version of the "Avalon jar packaging tool".


To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message