You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2003/11/30 09:56:52 UTC
Re: [repository] news - update - etc.
On Sunday 30 November 2003 16:59, Stephen McConnell wrote:
> Builder builder = new DefaultBuilder( context, artifact );
> Factory factory = builder.getFactory();
May I suggest that the Builder and Factory gets a bit more specific names?
Although packages helps the compiler to separate different classes apart, I am
not that capable and would like to know the type of the factory as part of
its basename.
Cheers,
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [repository] news - update - etc.
Posted by Niclas Hedhman <ni...@hedhman.org>.
I need to reply in smaller entities. (An I BUILD those entities with my
MailClient, Inferring does the "QUOTE" mechanism in a mail client be a
Builder???)
On Sunday 30 November 2003 20:35, Stephen McConnell wrote:
> 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
This IS scope/context (and I am not even talking about it from a programming
point of view, but more of semantics), or call it whatever you want.
The WORD Builder is too generic. That's my only objection. You look at it too
much from a programming perspective...
Cheers,
Niclas
P.S Now I can continue with my online game, download of map almost complete
:o)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [repository] news - update - etc.
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 30 November 2003 20:35, Stephen McConnell wrote:
> >Q: Is it used to instantiate all objects?
>
> No. Only objects that require a classloding context, parameterization,
> and a managed execution environment.
Ok, Again... You ARE limiting the Builder/Factory scope. I refuse to
acknowledge that it is as generic as Factory (not even the GoF Factories are
without scope.)
Cheers,
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [repository] news - update - etc.
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 30 November 2003 22:58, Alex Karasulu wrote:
> Wait for documentation and examples or take a look at the ones Steve
> has already referred to. It helped clarify a lot for me.
My opposition is not against the whole idea. I can appreciate that.
What I appreciate less, is that 45 frameworks out there have various factories
and builders, some of them with a preprended name, some not.
I am basically making an argument similar to "against java.sql.Date", please
introduce new terminology if required, but using too generic names always
leads to problems (please check the usage of Entity.class around the world to
see what I mean, and I don't mean to replace Artifact with Entity).
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [repository] news - update - etc.
Posted by Alex Karasulu <ao...@bellsouth.net>.
Niclas,
I think Steve's right about leaving these constructs generic because
their context depends on their use and the application space. I too
am very nit picky about names - I think Steve will agree to that since
I have bugged him several times about it. However because I did not
go as deep into the problem I was partially informed. After dealing
with these issues the names are apparent. I think documentation will
also clarify things. Also there may always be a better name out there
so keep on thinking and suggesting - this never hurts.
> 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).
The problem is you are free to do what you will with it. This is like
ClassLoaders you don't care what your loading but must allow for the
full gambit.
>
> >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.
This is interesting in that I thought we had a mechanism to just call
a method without instantiating anything as well. Basically to
generalize further the API is here to dynamically build the appropriate
ClassLoaders based on an artifact and its dependencies. It allows you
to then invoke or instantiate then invoke methods on classes and objects
respectively. The whole problem we attempt to work around is that you
don't have the classes in the invoker's ClassLoader and thus need to
use these generic constructs and things like reflection to kick off the
process.
If I'm confusing readers even more just disregard this email.
> >Maybe you think this is trivial matters, but it is about improving
> readability
> >and ease of understanding.
Wait for documentation and examples or take a look at the ones Steve
has already referred to. It helped clarify a lot for me.
Cheers,
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [repository] news - update - etc.
Posted by Stephen McConnell <mc...@apache.org>.
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:mcconnell@apache.org
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [repository] news - update - etc.
Posted by Niclas Hedhman <ni...@hedhman.org>.
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.
> 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? ObjectBuilder? ArtifactBuilder? BootstrapBuilder?
ImplementationFactory?
(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, 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.
The fact that I can't derive the scope/context is IMHO already a weakness.
Q: Is it used to instantiate Avalon components?
Q: Is it used to instantiate non-Avalon components?
Q: Is it used to instantiate all implementations that has a declared
interface?
Q: Is it used to instantiate all objects?
Q: Does it replace keyword "new"?
Maybe you think this is trivial matters, but it is about improving readability
and ease of understanding.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [repository] news - update - etc.
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>On Sunday 30 November 2003 16:59, Stephen McConnell wrote:
>
>
>> Builder builder = new DefaultBuilder( context, artifact );
>> Factory factory = builder.getFactory();
>>
>>
>
>May I suggest that the Builder and Factory gets a bit more specific names?
>
>Although packages helps the compiler to separate different classes apart, I am
>not that capable and would like to know the type of the factory as part of
>its basename.
>
Both Builder and Factory are completely type neutral. 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.
You could write a specialized builder that declares jar dependencies as
part of its associated metadata, and in that builder you would be able
to cast a factory to a application specific factory.
SpecialBuilder builder = new SpecialBuilder( context, artifact );
SpecialFactory factory = builder.getSpecialFactory();
However, I'm focussing more on a generic embeddor that will enable the isolation of appication specifics into a handler that is plugged in dynamically.
For example:
Artifact factory =
Artifact.createArtifact( "hedhman", "niclas", "1.0" );
Handler handler =
Artifact.createArtifact( "hedhman", "niclas-cli", "1.0" );
Builder builder = new DefaultBuilder( context, factory, handler );
builder.getHandler().handle( builder.getFactory());
Inside a handler you would be able to do all of the casting to specilized factories, context objects, whatever - because a handler classloader would be constructed relative to the classloader established for the factory (which is what I will give you the environment you want).
In practical terms this means that the repository-main application can establish a merlin factory (or a Fortress factory or a Niclas factory, or whatever), then establish the embedded context handler (e.g. CLI, web-app, unit-test, jelly-scrip, etc.) - without reference to the application classes. If you take a look at the test case currently under sandbox kernel/test you will see that the only dependency is the repository-main which only includes the repository API, SPI and a few utilities. Everything is constructed from this micro-loader (including the actual repository implementation itself).
How does that sound?
Steve.
>
>
>Cheers,
>Niclas
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org