Niclas Hedhman wrote:
On Sunday 30 November 2003 17:45, Stephen McConnell wrote:
Both Builder and Factory are completely type neutral.
I disagree. It can't make coffee cups, motorbikes or potato chips.
It can if the artifact that is supplied references a factory that instantiates coffee cups, or a factory that instantiates motorbikes, or a factory that instantiates potato chips. The result of building something is 100% dependent on the artifact that is being built. Keep in mind that this is the most primative stage - no notion of avalon, component or anthing like that - simply the notion of an Artifact, a Factory described by meta-information associated with the artifact, and an Object produced by the Factory.
Towards the end of this long-ish email is a description of this relative the main method which hopefully clarrifies a few things.
This is specifically to allow the management of factories by a bootstrapping system that does not know about a specific application. More importantly, the generic builder does not have application specific classes in its classpath.
So is it ApplicationBuilder?
Could be if the suplied artifact references a factory that creates applications.
ObjectBuilder?
Could be if the suplied artifact references a factory that creates Objects.
ArtifactBuilder?
No.
An Artifact is a protocol independent logical representation of a physical resource (for example "merlin:merlin-impl;3.2.2" is an artifact specification - it says nothing about its physical location or transport protocol). Many artifacts may be used by a builder to construct a factory.
BootstrapBuilder?
From the perspective of the Repository SPI - No.
The inital context that is supplied to a builder is where the bootstrapping occurs. However, the Repository APIs provide the framework that an application like Merlin can consider this facility as a bootstrap mechanism. However, to call the Build a BootstrapBuilder would be applying notions that are specific to a usage example.
ImplementationFactory?
Partly.
More specifically - the builder provides:
1. importing of physical artifacts required to meet an instantiation objective
2. assembly of a classloader heirachy
3. establishment of a default or cutomized criteria
4. instantiation of a new instance relative to cutomized criteria
5. handling of the established instance
(Sorry for not looking into the details yet. Just dislike too generic names, as Factory, Builder, Entity, which all exist in all frameworks, which makes stuff harder to read.)
<snip content="explaination" />
How does that sound?
"Type" is irrelevant to this.
No matter what, the Builder/Factory has some form of context/scope to which it belongs,
Sorry - nope.
The Builder knows *nothing* about the scope. A *Factory* implementation knows about scope and it exposes this though a map containing the default criteria. A client (such as the test case code I included earlier) knows about the application context and can update the factory supplied default criteria (e.g. setting the "merlin.debug" property to a value). The map implementation knows about the application context and can validate that the value supplied is ok. Once the client has completed criteria updating, it can request object instantiation by the factory. The factory implemementation then deals with whatever it means to instantiate an instance.
and I am seeking to minimize the number of standard names, which just makes it so harder to understand, especially if they overlap with other frameworks.
There is documentation underway - in particular the stuff to do with Builder and Factory is real important.
The fact that I can't derive the scope/context is IMHO already a weakness.
You don't need to "derive" scope or context because you are already 100% in control of this. You declare the artifact which defines the factory scope. You get the default context from the factory (via the criteria), and you update this context and pass it back to the factory whe creating an instance. I.e. your in complete control of what is happening - the Builder and Factory interfaces represents the boundaries between you (a client in classloader X) and an application (in classloader Y).
Q: Is it used to instantiate Avalon components?
No - it is independent of the framework. It is used to instantiate an object within an appropriate runtime structure and execution environment. It is equivalent to the static main method except that it provides (a) defaults, (b) places the target in an appropriate classloader, and (c) establishes the execution environment.
Q: Is it used to instantiate non-Avalon components?
No - its not about components. Its about object instantiation under an appropriate classloader, in an appropriate context, within an appropriate execution environment.
Lets dig into these things a little deeper:
(a) classloader - goes and get metadata describing the structural
dependencies, builds the classloader relative to the current
classloader context and establishes a target factory within
the new classloader (all of this is derived fro the artifact
reference) (b) context - provides a contract between client and factory that
allows a client (that is outside of the app classloader) to fully
parameterize the factory using defaults supplied by the factory
and the subsequent instantiation of an object relative to the
parameterized context (factory provides full defaults via a map,
map implementation handles defaults creation, also handles
parameter value validation) (c) establishes the execution environment that determines the
lifespan of the object that is created - for example, a simple
execution environment is the association of a shutdown hook
and the maintainace of the object in a thread that waits for
a jvm shutdown event - other example of an execution
context is a JMX server that registers the object supplied by
by the factory
Q: Is it used to instantiate all implementations that has a declared interface?
The facility has been designed to eliminate the necessity for dependence on interfaces. Currently the Factory interfaces is required but this is temporary. The factory implementation is designed to be driven by reflection based on a very small set of patterns. These include factory constructor patterns and the factory interface operations (three method) which are all based on elimentary JVM type (in partiular - the map interface for supply of a default critea and receipt of instantiation criteria).
Q: Is it used to instantiate all objects?
No. Only objects that require a classloding context, parameterization, and a managed execution environment.
Q: Does it replace keyword "new"?
No.
It would be more correct to say that is replaces "main" when appropriate.
1. main limits parameters to String values 2. main limits the parent classloader to the system classloader 3. main does not provide a framework for flexible parameterization 4. main's usage of optional extensions as a repository of physical resources is insuffient and unreliable
What this provides is:
1. control over the classloader parent 2. ability to contstruct a classloader hierachy (api/spi/impl) 3. provides a framework for defaults establishment 4. provide a framework for typed parameters (e.g. File, KeyStore, etc.) 5. enable typed parameter validation 6. backed by a repository model that handles automated resolution and caching of dependecies 7. control over the execution environment
Maybe you think this is trivial matters, but it is about improving readability and ease of understanding.
Most of the last few days has gone into improving APIs with the specific objective of making things clean and consistent with respect to the scope and context of the object model. This is very low level stuff - dealing with Object instantiation before we even consider things like "what is a component". It is simply about providing the right context and environment for an embedded object.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/ | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
