I quickly skimmed the threads on this and I didn't pick up what the advantage
was it making this a "container". The only thing I seen was a tighter
integration between DAS and SCA. But as I understand it me this is really a
tighter integration between DAS and Tuscany implementation of SCA. In general I
think we should be promoting building services on SCA not Tuscany. When new
bindings/containers extension are proposed for Tuscany we should first consider
why SCA/ binding/components were inadequate and see if there is something the
SCA architecture can improve that would have made it possible.
The major down side I can see to the container approach is that it can't be
reused in another SCA implementation.
Jim Marino wrote:
Hi Luciano,
Is the DAS container a component or binding? If it is in the former, I
would think it should go under container/container.das, otherwise
binding/binding/das/
Also, the dependency in the module should be against a version of DAS
and not the DAS project directly so that it is treated as an external
dependency like Axis or OpenEJB.
Jim
On Nov 8, 2006, at 5:08 PM, Luciano Resende wrote:
Hi Guys
Amita have started work to expose DAS as an SCA container, and we are
looking what would be the best way to get collaboration on continuing the
task. One of the ways we were thinking was to clean-up what is available
today and get it into the trunk, so we could share and continue
contributing
by submitting patches. Is that the way to go ? Any other ideas ? If
that's
the case, would the right place to have the container be around :
/java/sca/containers ? and then we would have a client available in
das/samples/das.container.client ?
Toughts ?
- Luciano Resende
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
