[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 228: proposal
This week Mike and I took and AI to talk to Spring C&I implementers in our respective companies and come back with a proposal to resolve. Here is a list (non-exhaustive) of proposal that we can use to resolve issue 228 with my recommendation (based on implementer feedback) as to how to resolve it: 1) Align it with the POJO spec. That is: a) if the bean class does not implement any remotable interfaces then only one SCA service is exposed; the interface of the SCA service is the same as the name of the class. b) if the bean class implements one or more remotable interfaces then one SCA service is exposed per remotable interface. 2) Only one SCA service is exposed per bean regardless of which interfaces the bean class implements (or does not implement) -- a) if the bean class does not implement any remotable interfaces then the interface of the SCA service is the same as the name of the class b) if the bean class implements exactly one remotable interface then the interface of the SCA service is the same as the name of the remotable interface c) if the bean class implements > 1 remotable interfaces then do (a). 3) Same as (2) except in case of (2c) raise an error. 4) Same as (2) except in case of (2b) and (2c) raise an error. #1 is aligned with the POJO introspection rules (less surprise for the reader), but #2, #3 and #4 turn out to be simpler. #1 is less simple for the case where the bean class implements multiple remotable interfaces. Since the generated SCA service name has to be unique within the app context, the name now has to be mangled name consisting of the bean name and the interface name. Something like "beanName-fullyQualifiedInterfaceName". I also think that it is going to be rare that you have a bean class that implements two (or more) remotable interfaces, you want both the interfaces to be exposed to SCA, *and* you do not want to edit the app context file to include SCA extensions. Obviously, if you edit the app context file you can get exactly you want. My current thinking is that #4 is probably the easiest to implement with a few (but not important) restrictions that one can get around when using SCA extensions in the app context. Comments? -Anish --
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]