Thanks for this info, Oki, it explains quite a few mysteries. I am going back over my notes to find all the bits that it clears up.
A disadvantage of Avalon is that the learning curve makes it tough for 3rd parties like myself to contribute. My hope was to implement this one neat little feature and contribute it back to James, but doing it within the Avalon style multiplied the time so much that it wasn't worth it. Not that Avalon is a bad thing, just that it discourages drip-drip-drip development. ...what I'm doing now is an alternate implementation of the Mailet interface. So in a way this should contribute back to James, in the sense that I'm giving the Mailet design a workout. best, Lucas > -----Original Message----- > From: Oki DZ [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 12, 2001 9:15 PM > To: James Developers List > Subject: RE: spoolmanager > > > On Wed, 12 Dec 2001, Lucas Gonze wrote: > > I'm just trying to wrap my head around how control flow works, given > > that parts are in James code and parts are in Avalon. A thing that's > > fairly confusing is which parts of the conf files are handled by James > > and which parts are handled by Avalon. Some trial and error testing has > > shown that it is indeed the conf file, aka Avalon, that's loading it. > > Indeed, it's Avalon (Phoenix, to be exact) that loads every blocks defined > in james-assembly.xml (this file becomes assembly.xml later). assembly.xml > defines the services (provided by other blocks) to be used by each of the > blocks. server.xml defines what name of the log file to be used for each > existing block. james.xml defines the configuration for the James block. > > In every Avalon block source code file's directory, there is an .xinfo > file that defines its dependency (from other blocks) and the service it > provides (this service is defined in an interface). There is a file called > Manifest.mf that contains all the blocks used in the application, James in > this case. I guess the purpose of Manifest.mf is for defining what classes > to be packaged in the james.bar. So don't forget to include your new > blocks in this file. > > If you want to create a new Avalon block (ie: a class that provides > services to the other existing ones), take a look on James.java or any > other blocks for the interfaces they implement. Avalon uses interfaces for > telling the system (Phoenix) what kind of classes it is loading; if the > class implements the Block interface, then it becomes an Avalon block; if > implements the Component interface, then it becomes a component. But I > think, Phoenix loads blocks only; components are instantiated by the > blocks later. > > For every block or component, you can have the kind of activities you want > to implement; eg: Configurable, Composable, Initializable. If you have a > Configurable class (a class that implements the Configurable interface), > then the system expect that you define configure() method in the class; if > it is a Composable, you'd need to implement compose(), and Initializable > needs initialize(). The system will invoke the methods in sequence (you > can check this in the "Developing with Avalon" .pdf file that's provided > in the web site). Which one to implement depends on what you want; if you > need to get into (the instance of) the ComponentManager, then you should > implement Composable; if your class need to be configured (read it from an > .xml file), then you should implement Configurable interface. > > There are quite many of files to edit/create for adding new blocks into > James; <your class>.xinfo, Manifest.mf, assembly.xml, server.xml, > james.xml. It would be nice to have the (your class') configuration into > james.xml; so that you can just use the system's Configuration instance in > your new block. If you use other libraries (.jar files) other than what's > supplied by James, you need to edit the build.xml file too; see at the > element that builds the .sar target. > > Oki > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
