Peter,
fun - now I wish I was a Londonite ;)
Far too much booze was imbibed for lucid conversation!
Yes, but perhaps an Ant task before then. Automation is more important that interactive replacement.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
Will have a look again. I think my brain rebooted at first read.
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: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 ? ;)
"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).
Re Interfaces, I'd like to see support for multiple versions of the same interface.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 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 ;)Invalidated? You mean dependancies. EJB need to know when Tomcat is stopping? Perhaps Tomcat can't stop until things that use it have?
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 ;)
- Paul H
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
