avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <aok...@bellsouth.net>
Subject RE: [repository] news - update - etc.
Date Sun, 30 Nov 2003 14:58:29 GMT
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


Mime
View raw message