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."
I'm thinking about this - more notes at the end of this email.
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.
This is way things were. But this has changed. There is no longer a portability issue between containers because there is only one container - is the reference container for the Avalon Framework - and its name is Merlin. The Merlin container follows the Avalon Meta specification which requires that context dependencies are explicitly declared by a component (just like service dependencies). The specification also include the definition of a set of standard context keys.
urn:avalon:name urn:avalon:partition urn:avalon:home urn:avalon:temp urn:avalon:classloader
Based on this set and through the use of alias names - it is possible to map legacy Avalon systems such as Phoenix or Fortress.
The Avalon Composition package defines a specification for the way in which component deployment scenarios are created - and this allows the creation of custom context entry solutions.
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?
For the purpose of discussion we can collapse a Parameters instance under a Configuration - so from that view point I'll try to detail the difference I see between Context and Configuration.
Context - typically supplied environment information (for example
a temporary working directory, or classloader) that is establish
by the container - context entries will typically reflect aspects
of you installation of system environment Configuration - typically supplied in relation to a particular
component relative to an application requirement - unlike context,
information is normally provided by an assembler as part of the
tailoring of typically static information to achieve a certain
runtime behaviorWhat 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 traditional assumptions concerning lifecycle management are that an component instance is never exposed to a consumer before it is fully processed. In practice - it simply does not matter if you do things sequentially or in parallel because sooner or later you end up in the same situation because anything up to initialization can be logically collapsed into a logical initialization step. Using constructor based injection is an example of the collapsing of lifecycle stages into a single step.
However - there is an valid argument for the separation of the notion of supplying references to services, as distinct from those service being available. This is what Niclas has been talking about - a "service availability" contract.
In the meantime - I do have a demo tucked away somewhere that demonstrates a working system that includes recursive dependencies.
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().
Think about things from the component point-of-view instead of the container ... i.e. when the execute method is invoked it knows that is can expect everything it needs to be available. It doesn't make any difference whether a component is executable or startable or neither - the container/component contract says that you will have what you need (and if that rule cannot be fulfilled - then you will not exist).
But yes - the Execute interface is somewhat lacking in concrete semantics. This is something that can addressed as part of a framework 4.2 overhaul.
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.
Correct.
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.
This is legacy related to different containers. Yes - in effect ServiceException is redundant if the contract semantics are clear that the lookup is based on a prior stated requirement. Unfortunately changed this is something that will have to be pushed out to framework 5.0
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.
Your certainly focusing on the correct spots.
I'm kind of moving toward a conclusion that a framework focused specification could be improved by taking a step back and looking at the different specification areas (i.e. not focusing strictly on any particular package):
Here is an initial TOC for an Avalon Specification:
* component specification
- component descriptors
- tags
- packaging
- lifecycle artifacts
- context
- configuration and parameters
- service manager
- logger
- artifact delivery
- injection
- staged
- lifestyles
- transient
- singleton
- thread
- pooled* deployment specification
- kernel specification
- environment
- repository properties
- platform properties
- deployment directives
- component
- context
- dependencies
- stages
- extensions
- profiles
- categories
- container
- classloaders
- component and container nesting
- includes
- target overrides
- configuration
- categories
- permissionsWDYT?
Cheers, Steve.
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
