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]