ant elder wrote:
On 4/29/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: jsdelfino
Date: Sat Apr 28 16:52:22 2007
New Revision: 533445
URL: http://svn.apache.org/viewvc?view=rev&rev=533445
Log:
Changes to make sure that model factories can be switched and the
that the
runtime does not assume specific factories or implementation classes.
Could you say a bit more about what this change is about? I'm not sure I
understand why its a good thing for all the extensions to now have to
hard
code all the default factories?
...ant
The change is about cleaning up the code which was hardcoding the model
factories in various places in the runtime, and would basically make it
impossible for an extension or a Tuscany runtime assembly to switch the
model factories to others than the default ones.
Initially, the factories were hardcoded by the processors, introspectors
and various other pieces of the core runtime.
Now the factories are not hardcoded by the core pieces of runtime
anymore, and an extension can choose - to hardcode :) - a specific
factory, including the default one.
The idea is to allow the choice of factory to be externalized. Ideally
it should be chosen by the SCA runtime assembler. For example if I want
to assemble an SCA runtime integrated with Spring I should be able to
choose the model factory that creates Component model objects backed by
Spring bean definitions (like the factory in the tuscany-core-spring
module). This was not possible before as a number of pieces of runtime
were hardcoding a new DefaultAssemblyFactory() instead of having the
factory "injected" - to use a trendy term :) - into them. This is now
possible as the factory is now passed to (oops, injected into) them.
Another example is that the Java module activator will probably want to
use a specific factory to create model objects for its services,
references. and properties augmented with Java specific info. For
example for a Reference created by the Java class introspector, we'll
probably want to have the Java member (method or field) defining the
reference stored in the Reference model object. So in this case, the
extension developer will actually be happy to be able to choose the
factory to use. The Script implementation extension may be able to
follow a similar approach to be able to use specific implementations of
Service, Property or Reference that can carry script specific info as well.
An option, for the script implementation for example, would be to
continue to hardcode the factory inside its artifact processor, or
construct instances of model implementations using "new" directly even
without using a factory, but that will limit its reusability as it will
basically tie it to a specific implementation of the assembly model.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
