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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]