Hi Jean-Sebastien, I am currently working on porting Celtix binding based on the new SPI. Jim checked in a brunch of skeleton code for Celtix binding into sandbox early this week, what I am doing at the moment is adding some unit tests for individual pieces such as Service implementation, Reference implementation, loader, invoker etc, most of them are to make sure things are working as expected on Celtix side. What I have not figured out yet is how to write test to check those components are loaded by Bootstrap and behave correctly in Tuscany runtime. I have took a look at SPI unit test, there are some tests there already, but I would like to see people adding more tests cases to show how Reference, Service, loader, invoker etc are initialized, loaded and how they work together in an end to end workflow? Well, maybe this is not unit test anyway, but sth close to this will be very helpful. Basically I have no problem to write unit test to test internal functionalities of my extension component, but I need to know how my extension components are initialized(or injected), loaded and invoked by some higher level components (Bootstrapping, tuscany container etc?) either by unit test or an end-to-end simple demo.
Thanks, Jervis -----Original Message----- From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 21, 2006 4:38 PM To: [email protected] Subject: Tuscany SPI interfaces I'm trying to implement the sample ruby extension and running into some issues. I'm implementing an AtomicComponentContext (with the code in the head stream) and also trying the equivalent AtomicComponent with some of the code in the sandbox. I want to be able to implement my extension class without having to depend on base Tuscany runtime implementation classes, so I'm just implementing the SPI interfaces. Unless I missed something (and it's very possible since I don't understand all the pieces yet) here's what I found: - with the code in the head, my AtomicComponentContext needs to implement 15 methods; - with the code in the sandbox, I have to implement 25 methods. And this is just one class, I'm not even implementing the builders or invokers yet... I think that in both cases this is too much. It looks like the experiment in the sandbox is attempting to provide a simpler programming model for these extensions by hiding some of the complexity in base implementation classes, but I think it will be better to define a set of independent interfaces and make some of them optional. In other words if my extension does not wish to implement one of the interfaces, then it just doesn't need to, and the runtime should assume some default behavior, instead of forcing me to implement all the 25 methods... Another thought is to allow the contract to be implemented with multiple objects specialized in each aspect instead of one big object with 25 methods. As I'm going through the implementation of the ruby component implementation extension, I'm trying to come up with a short list of requirements and methods that I think we really need to implement, and with that list I'd like us to prototype simpler SPI interfaces. If anybody is interested in helping, please feel free to jump in, it would really be great if we could do a binding extension in parallel, and also if the people who actually developed some of the existing extensions could come up with the requirements they've seen in terms of SPI and proposals to improve our extensibility story. Thanks, -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
