avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: Minutes from AvalonCon #1
Date Fri, 26 Oct 2001 12:45:09 GMT

>fun - now I wish I was a Londonite ;)
Far too much booze was imbibed for lucid conversation!

>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 ;)
Yes, but perhaps an Ant task before then.  Automation is more important 
that interactive replacement.

>>P2) Avalon needs to evaluate class loading w.r.t kernel and its
>>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 -
>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
Will have a look again.  I think my brain rebooted at first read.

>>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 ? ;)
Perhaps a little with infrastructure.  How about we ask people we are 
helping in the list to contribute what then feel to be a decent FAQ 
point after we've helped them in the list.  Vinay's cryptic:

    "How does one service access the instance of another Service.?"

Is a good example of not knowig where to start (as we're all so familiar). 

>>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:
>>*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.
Re Interfaces, I'd like to see support for multiple versions of the same 

Re Classloader, you know my daft ideas.  I'll re-read your RT thread,

>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 ;)
Invalidated?  You mean dependancies.  EJB need to know when Tomcat is 
stopping?  Perhaps Tomcat can't stop until things that use it have?

- Paul H

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

View raw message