On Aug 30, 2006, at 11:59 AM, Yang ZHONG wrote:
Thank Ant so much for details, that's very helpful!
I'll update the API:
2-1. remove INSTANCE
2-2. demonstrate the SCA way to get SymbolSpace.Registry
implementation in
JavaDoc
Why do we have the "inner" interface? I agree with Jeremy that it
doesn't seem very intuitive.
SymbolSpace.Registry is the generic registry interface, it doesn't
prevent
us from having SCA specific interface(s).
I can come up with a WSDL Registry interface proposal. Can someone
tell me
which model is used by SCA: WST, WSDL4J, EMF, home grown or
anything else?
On 8/30/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
I'm having trouble parsing this. Are you talking about an SCA
registry, or a WSDL registry, or the mechanism for locating it (via
IoC as Ant described or something else)?
I was saying that in an IoC world there is /no/ provider part of the
API - a user never locates anything, they declare dependencies and
the container resolves them. The dependency would be on the actual
client interface (SymbolSpace.Registry I guess but I've already
admitted to not grokking the interfaces).
--
Jeremy
On Aug 30, 2006, at 11:28 AM, Yang ZHONG wrote:
> Can someone propose a SCA specific API mentioned by Jeremy please?
> Something like
> interface ScaRegistry
> {
> Definition getDefinition (String nameSpace);
> Message getMessage (QName);
> }
> I don't know the SCA requirement much enough to make such proposal.
>
> At the same time, we can practise IoC in ScaRegistry service
locating.
> I hope I can learn from that practice and update the registry
> generic API
> accordingly.
>
> Thanks for pointing out a nice mechanism.
>
> On 8/30/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>>
>>
>> On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
>>
>> > As part of Tuscany there should not be any mechanism in a API
for
>> > "service location" - that is the responsibility of the IoC
>> container.
>> >
>> +1 (which nicely avoids external dependencies on some locator
>> implementation and evil Singletons)
>>
>> > --
>> > Jeremy
>> >
>>
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
>
> Yang ZHONG
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
