On Wed, 2004-03-10 at 03:53, J Aaron Farr wrote: > 1. Why do I use Avalon?
Strangely enough, many of my original goals in using Avalon have been overtaken by events. I'm not really a big proponent of COP - I think it doesn't usually achieve its stated goals of reuse and it leads to some very awkward designs. That said, I use Avalon because it does standardize a fairly loose life-cycle model for significant subsystems in my project. This, together with the multiple-classloader layout, offers some promise for very interesting serviceability and maintainability possibilities in the future. > 2. What do I feel Avalon's mission to be? To set the conventions for COP in the Java community. > 3. Where do I see Avalon by the end of 2004? Solid specs for the framework contracts and a good RI. > 4. How do I feel about Avalon as an umbrella project vs. a single > product? I think the "umbrella project" approach is a very bad idea. The number of different containers is already confusing to new adopters. Stephen's comments about fragmenting the community are well taken, too. The Avalon project is far too young to become a "parent" project for a variety of containers. Get something solid built first, work on solidifying the community - get some of those who are working on minor container variations to work within the Avalon community, instead of creating a splinter cell. Get us a nice solid RI that can really show the benefits of the framework - management, multi-server deployment, etc. *Then* if there's a clear case for specialized container variants, start refactoring the RI into a core-and-specializations structure. > 5. Should there be a formal framework specification? Absolutely. Without it, Avalon isn't really a framework. It's a product. The framework spec is really just a precise way of saying what we agree the various framework classes really mean. > 6. If so, what should it consist of? Hard to say. Certainly there should be a clear statement of the component lifecycle - not from the component's point of view as is currently done on the site, but from the container's point of view. There are lots of inter-component issues that are completely ignored by the current docs, mostly because every place someone has an opportunity to describe the life cycle, it's from the perspective of the component, not the container. For example, it came as a big surprise to me that my components weren't taken through the life-cycle in parallel (assign everyone a logger, then contextualize them all, and so on). The point of the framework specification is to give a component writer a definitive definition of the environment in which the component will execute. This is the *only* way to let anything but the simplest components be reusable. Today we don't even know what we should be passing as the parameter to ServiceManager.lookup() without knowing what container we're running in. Beyond the framework spec, I think there should be a single, strong reference implementation. There's certainly plenty of room for discussion as to whether the RI should be minimalist or complete. The minimalist approach would just providing an environment in which a valid collection of components will run correctly. "Advanced" issues are left to the container implementations. As the community gains consensus on the "right" approach, it can be standardized and included in the RI. This is the approach the JavaBeans folks had with the BeanBox. The complete approach, on the other hand, tries to expand the RI to include management, dynamic component loading, provides some very useful common components, etc. It tries to be a real option when choosing a container. This is the approach Sun took with Java. Personally, I'd prefer the latter approach. My projects tend to be long-running server apps. Having the RI as a legitimate container for these kinds of apps would be a real boon. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
