So, the basic idea was that AccountDataServiceDASImpl should implement both AccountDataService and CustomerIdService, but @Service was not able to handle a list of more than one interface. Also notice that CustomerIdService includes most of what is in AccountDataService instead of extending it, which the config code could not handle either. I am assuming both these problems have been resolved, so this should be able to be fixed now.

So, to fix the implementation:

1- AccountDataServiceDASImpl needs to implement AccountDataService and CustomerIdService and use as it service annotation: @Service(interfaces={AccountDataService.class,CustomerIdService.class}) 2- CustomerIdService needs to only define getCustomerIdByPurchaseLotNumber and getCustomerIdByAccount 3- AccountDataServiceDASImpl needs to also implement getAccountLog, given that AccountDataService defines it

----- Original Message ----- From: "Luciano Resende" <[EMAIL PROTECTED]>
To: "tuscany-dev" <[email protected]>
Sent: Wednesday, September 27, 2006 12:19 PM
Subject: BigBank account service


After looking at BigBank article and comparing with the current
implementation available in Tuscany i have the following question :

BigBank article :
http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-sca/SCA_BuildingYourFirstApplication_V09.pdf

Today, AccountService is implemented the following way :
AccountDataServiceDASImpl <<-- CustomerIdService
And I would have expected to have it as : AccountDataServiceDASImpl <<--
AccountService

Does anybody know the history on why this is implemented this way ?

I would like to clean this up and make AccountDataServiceDASImpl implements
CustomerIdService as described on the BigBank application.


- Luciano




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to