ant elder wrote:
As part of the modularization work its been suggested separating the Java
component container out from the core to be an extension just like the
other
extensions. For example, see [1] and diagram [2]. Lets have a
discussion on
this specific proposal trying to get some consensus and then vote on
it to
get closure.
One of the reasons I like this proposal is it will help solidify the
extension SPI. With the Java container included as part of the core it
doesn't have to use the SPI so can get away with doing things that other
extensions can not. This means the SPI falls behind kernel changes and
its
sometimes not possible to implement another container without just
copying
bits of the core code.
Something that hasn't been proposed yet is exactly how the core would
be put
together if it wasn't using SCA assembly. The diagram [2] suggests
"Either
hand-wire the built-in system services or use an IoC container". Could
there be a specific proposal on how this would be done?
I think it's pretty simple. One of the benefits of IoC is that your
objects do not depend on the framework or container used to assemble
them. Our kernel is basically an assembly of POJOs (this is good) wired
together by... our kernel (and this part is causing chicken and egg
issues). The good news is that, thanks to IoC, we should be able to use
different techniques to assemble these POJOs. There are many ways to do
it. An obvious way is to write a page of code or two to do the wiring
"by hand".
Basically assuming 2 Tuscany "system components" PojoA and SysPojoB:
public class PojoA implements A {
private B b;
@Reference
public void setB(B b) {
this.b = b;
}
public PojoA() {}
}
public class PojoB implements B {
public PojoB() {}
}
Instead of using an SCA assembly description supporting special "system"
components like this:
<composite name="..." autowire="true">
<component name="ComponentA">
<implementation.system class="PojoA"/>
</component>
<component name="ComponentB">
<implementation.system class="PojoB"/>
</component>
</composite>
do something like that:
public class SimpleWiredByHandRuntime {
public A setupTheRuntime() {
A a = new A();
B b = new B();
a.setB(b);
return a;
}
}
This may be a good way to assemble our runtime, or maybe not. It seems
straightforward - to me at least :) - and won't cause any chicken and
egg problems. We will probably not know which is the best way until we
actually try, so I'd like to try this in one of our runtime assemblies
to make it concrete and help understand the benefits and issues (if any)
of such an approach. I think that we could live with different assembly
techniques in our various runtimes for a while and over time see which
one people prefer to use.
The main reason suggested against doing this so far is: "users (would)
need
to be familiar with two assembly mechanisms and that seems like confusing
and unnecessary complexity." [3]. I don't understand why users need to
understand or even be aware of how the Tuscany runtime is implemented?
I don't either.
...ant
[1] http://www.mail-archive.com/[email protected]/msg16034.html
[2]
http://cwiki.apache.org/confluence/display/TUSCANY/Kernel+Modulization+Design+Discussions
[3] http://www.mail-archive.com/[email protected]/msg16072.html
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
