Peter, >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 >>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 > 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). >> > >+100 > >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: >>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. > Re Interfaces, I'd like to see support for multiple versions of the same interface. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
