avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: Minutes from AvalonCon #1
Date Thu, 25 Oct 2001 10:10:15 GMT

fun - now I wish I was a Londonite ;)

On Thu, 25 Oct 2001 01:32, Paul Hammant wrote:
> 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.

yep. Most of the information required for this is available in the BlockInfos 
etc. If the manifest has also added entries to say something like 

Avaon-Block: true

then it should be easy enough for a GUI assembler to be written. I think ;)

> 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

Yep. I would like some feedback on the Random Thought I posted a while back 
in relation to this. If it is liked then I will try to implement it when I 
get the chance.

BTW the title of it was [phoenix] RT: ClassLoader hierarchy

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


volunteering ? ;)

> 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.

+1 Phoenix has needed this ever since we went from a 2-layer app to a 3-layer 
app. (About a year ago?). However before we can do this there is 2 issues we 
really need to resolve. One is the ClassLoader issue and the other is the 
definition of the interface.

The ClassLoader issue is partly discussed in the RT thread I mentioned in 
last mail. The other part of ClassLoader stuff we have to do is basically 
finish the org.apache.avalon.excalibur.extensions.* classes and integrate 
them into the DefaultClassLoaderManager. This would be easy enough to do I 
think. It just takes time ;)

The other is the definition of the interface. The problem arises is how do we 
know when the interface has been invalidated? We could let the application 
know with another Event listener interface but that seems like overkill. The 
other alternative is to make it a Remote interface but I know how much you 
hate that ;)

The rest of it (ie JNDI implementation and infrastructure) is ready to go. 
Just needs decisions on design to be made ;)



 Mark Twain: "In the real world, the right thing never
happens in the right place at the right time. It is 
the task of journalists and historians to rectify 
this error."

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

View raw message