Hi Marcel, On Oct 21, 2012, at 23:08 , Marcel Offermans wrote:
> Hello Mark, > > Out of curiosity, did you want to exploit the behavior you expected? In other > words, do you have a use case for it? I was indeed working on something and wanted to try whether aspects services would fit for this use case. Basically I defined an interface for a service to retrieve records from a remote system. Multiple implementation may be registered in a whiteboard style. Some external systems don't supply values for all fields of a record, so I used service properties to specify which information is available in the retrieved records. Some fields can be deduced from other fields. For example, I have a service that is able to map an account ID from the remote system to the account ID in the internal system. My experiment was to create an aspect service that consumes the original retriever, wraps the records, such that internal account IDs are available and could therefore republish the service with a new set of properties. I also made another aspect service this way to deduce the value of an enum field using information from other fields. Things started to fall apart when I chained those two aspect services. In short, I expected to find a service when filtering on something like (&(accountType=INTERNAL)(directionType=*)), both of which were added / overridden by one of the aspect services. Anyway, I learned that using aspect services for an interface that is assumed to be used whiteboard style complicates things a lot. I'm already working out the solution I was about to use if I didn't want to try out using aspect services and I just wanted to check on the intended behavior ;-) Thanks, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
