Niclas Hedman wrote:
> Sorry to butt in...
>
> What happened to the XP voices in Avalon.
> Value; SIMPLICITY
>
> The simplest solution that can possibly work!
>
> Since the whole Attribute world requires tools, such as an Ant
> task or a standalone compiler, why not let that tool create the
> index file, and for each URI in the classloader just get the
> "/index.attrs", which can be fully populated with the whole
> sha-bang....

That depends on what "the simplest solution" is. The whole point of the
attribute compiler is to gather up *all* metadata and pass it on, in order
to have a single tool for that purpose instead of having a Fortress
metadata builder,  Merlin metadata builder and so on...

So the attribute compiler compiles attributes and nothing else.

If you want an index.attrs then fine, but that is

  a. *another* contract on top of everything.

  b. Probably not supported under Java 1.5.

(a) makes your claim of the simplest thing fall.

(b) makes it fall even further. When Java gets attributes it will most
certainly *not* support your index.attrs. This means that, since the
syntax for attributes will have changed, will have to:

 1. Write an "attribute indexer tool" that must be run.

 2. Stick with "our" attributes.

The objective with this proof-of-concept is to show that everything can be
solved with attributes and that we won't need *any* custom tools as soon
as Java1.5 is out.

The index.attrs moves a lot of ugliness into the Attribute compiler and
adds contracts and makes us incompatible with Java 1.5 in a much greater
degree than we are now.

Recursively loading classes moves a lot of ugliness into the classloading
code, but will work in Java 1.5 as well.

It is not so clear cut what the simplest solution is.

Stephen McConnell wrote:
> Basically the jar file is scanned for meta-info entires

That sounds similar to Niclas's index.attrs approach. Again, I wanted to
see if attributes would allow us to *only use attributes* and not have any
specific packaging requirements.


Finally, regarding the speed of loading classes:

 1. The containers have hot-deploy features meaning that the applications
are loaded into separate classloaders managed by the container. This means
that we only really have to scan the classloaders that the container uses
to load applications.

 2. My experience is that just about every class ends up being loaded
anyway, sometime during server startup. So if this massive loading is done
at t=0 or gradually throughout the startup sequence is irrellevant. The
same goes for applications in the app server - load all classes
immediately or gradually during startup of application is really no
difference.

/LS

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to