On Mon, Jul 19, 2010 at 3:53 PM, Mike Edwards <[email protected]> wrote: > kelvin goodson wrote: >> >> I'm homing in on the 9008 failure, and someone may be able to help me >> shortcut my understanding. >> >> The expected output of the test is ... >> >> config.output[0] = "JCA_9008 request service1 >> operation1 >> invoked getService" + >> " expected IllegalArgumentException >> received for 0..n ref" + >> " expected IllegalArgumentException >> received for invalid businessInterface" + >> " expected IllegalArgumentException >> received for invalid reference name" + >> " expected null Service for unwired >> 0..1 reference" + >> " expected non-null Service for wired >> 1..1 reference" + >> " service2 operation1 invoked" >> but I see deviation from this output here in Service1CCgetServiceImpl >> at line 69 >> >> >> where the call to getService erroneously succeeds instead of entering >> the catch block >> >> try { >> componentContext.getService(Service2.class, >> "requiredRef"); >> responseAccumulator += " did not get >> IllegalArgumentException >> for invalid businessInterface"; >> } catch ( IllegalArgumentException e ) { >> responseAccumulator += " expected >> IllegalArgumentException received >> for invalid businessInterface"; >> } catch ( Exception e ) { >> responseAccumulator += " other unexpected exception >> received for >> invalid businessInterface: " + e.toString(); >> } // end try >> >> >> Kelvin. > > Kelvin, > > With all these API testcases, the responses are structured to indicate what > was expected or unexpected about the outcome of each invocation of the > relevant API method. > > OK, in this case componentContext.getService is being invoked to test what > happens if it is invoked for a specific named reference but the supplied > business interface does not match the interface declared for the reference - > as it says in the comment: > > // JCA-TA-9013 - IllegalArgumentException thrown if named reference does not > have the businessInterface specified > > So, "requiredRef" is declared as follows: > > �...@reference > public Service1 requiredRef; // 1..1 multiplicity > > ie it has a business interface "Service1". > > But the call to getService in this case supplies "Service2.class" as the > business interface - deliberately incompatible with Service1. > > getService MUST notice that the business interfaces don't match and throw > the expected IllegalArgumentException if they don't. Clearly, the > getService implementation in Tuscany is not checking correctly at the > moment!!
Indeed, so I've been trying to uderstand why that may be, but not yet plumbed the depths to get to an understanding of what's changed. Kelvin.
