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]