Minutes from unofficial AvalonCon, London Thurs 11th Oct 2001.

Present:
  Charles Bennett
  Kai Eris
  Liam Holohan
  Paul Hammant
  Pratik Patel

Notes taken by Liam, embellished by Paul and Pratik after the event.

P1) Assembly (or re-assembly) needs to be revisited i.e. possibly have a 
GUI as a alternative.
Reason : assembly is too hard for assembler, if they are not taking the 
defaults setup by the relevant build script.  Assembly seems to a 
programmers task, rather than an "assemblers" task.

P2) Avalon needs to evaluate class loading w.r.t kernel and its 
applications.
i.e. how do servers know that "this" is the http server. Or put another 
way, no inter sar communications or dependencies.

Of note is Tomcat's concept of trees - 
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html

P3) The FAQ needs to be updated.  Experience of "new guy" should be 
incorporated into the faq/docs ("Woods for the Trees" anti-pattern).

P4) Too many servers need sar files without proper federation. I think 
this is similar to P2. Perhaps this can be rephrased as:
SAR files should be able to register* their offered services to a 
'registry' in the kernel. This registry can take the form of a JNDI 
registry. SARs can do a lookup to attain if and what other SAR is 
providing a service. This can also be the location where a service can 
register itself as a 'default' service within a specific context. For 
example, Bay can register itself as the default internal webserver for 
handling webapps. An simple example is Tomcat4:
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/jndi-resources-howto.html.  
*Note we don't think the code of the block should do the registration, 
we think it is an XML specified assembler duty.



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

Reply via email to