On Fri, 2004-03-19 at 19:51, Stephen McConnell wrote: > Scott Brickner wrote: > > > On Mon, 2004-03-15 at 05:49, Niclas Hedhman wrote: > > > >>On Monday 15 March 2004 18:36, Daniel Frey wrote: > >> > >> > >>>Where do I find A4 (I don't know what it is, but seems to be important for > >>>my understanding)? > >> > >>This is Avalon slang for: Avalon Framework version 4.x > >> > >>Sometimes also called AF4. > >> > > > > > > I still think the question is a fair one. Where can we find a copy of > > AF4 to read? Is it actually written down somewhere or is it just some > > sort of collective artifact in the minds of the readers of the dev list? > > Hi Scott: > > It's all available here: > > http://avalon.apache.org/framework/ > > If you have any questions don't hesitate to post them to this list. > > Cheers, Steve.
Nah. Read that. It doesn't begin to describe the contract between the container and the components, which is what Niclas suggested that AF4 was. It barely mentions the various interfaces. The spot that would most likely address the contract is "containment", which says "Material in preparation." Here are a few contract-related questions that have come to mind as I've become familiar with Avalon... What's the point of Contextualizable vs Configurable - it seems like anything that uses Contextualizable is asking to be non-portable across containers, since nothing really says what one can expect from the context. But in practice, Contextualizable seems to be a "container-specific configuration" interface. Parameterizable kind of falls in that category, too. Again, why three interfaces to configure a component? What was the rationale behind deploying components serially? Wouldn't it be more useful (at least for components activated at startup) to have everything log-enabled before you moved on to contextualization, and so on. It would at least simplify some of the issues that make circular dependencies troublesome. The Executable interface isn't very clear either. I originally assumed (again, wrongly) that once all the startup components were deployed, they'd then all get started, then anything marked Executable would have its execute() method run - allowing execute() to be a sort of main(). The contract behind Serviceable apparently lets you hold onto the ServiceManager reference beyond the invocation of the service() method and to acquire new components on demand. On the other hand, every time you want to request a component, you have to code for a ServiceException. I'd expect it to be a relatively unusual situation for a ServiceException to actually be thrown outside of a debugging session, though. Components that hold onto the ServiceManager reference would rather just use hasService() during their service() method to verify that the ServiceManager has been configured with the required services, then have the ServiceException be a RuntimeException so the code doesn't have to be cluttered with exception handlers that never get invoked. These are just a few questions. I actually think I know the answer to most of them, now, but they *definitely* aren't addressed at all by the link you offered, but they're the kinds of questions I'd expect to be able to answer if I understood the interface contracts. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
