Better support for dynamic language components
There's been talk in the past about removing the requirement for things like script and dynamic languages to require a .componentType side file to define the services, references and properties when they can't be introspected. I'd really like to get support for this into the next release so have started having a go at it in r540132. Its a bit rough to start with so that anyone feels free to suggest or implement alternative approaches. I'm happy to rewrite it based on your comments or for others to help, at least now there's a couple of working testcases to show whats needed to be supported. The testcases where this is used are in modules\implementation-script\src\test\java\org\apache\tuscany\sca\implementation\script\itests\dynamic. The main changes are to include a dynamic field on the o.a.t.s.assemblyInterface and Operation which enable dynamic Interfaces and Operations to match any other Interface or Operation. One thing that isn't so good with the dynamic Operation is that it needs to keep track of which operation was called, so right now thats in a ThreadLocal, there must be something better, maybe having the operation name in the Message? Another change is the addition of a ComponentPreProcessor interface which implementations can implement so the assembly CompositeBuilder calls out to the implementation impl before wiring up the component. One thing I can't see how to easily support is a dynamic component having a reference wired to another dynamic component, as you need some sort of proxy object for the reference which has the possible methods on the proxy interface. I guess for languages which support something like a "no such method" function the proxy object could use that, but we'd need to be injecting some language specific proxy object supporting that for the reference. That would be a fun thing to look at if anyone is interested... ...ant
Re: Better support for dynamic language components
Hi Just started looking at this in the context of bringing the aggregator sample to the Java runtime. I like the idea of having a dynamic interface as an option as it reduces the amount of configuration. The term dynamic term confused me to start with - I initially thought this was about constructing scripts with dynamic invocation style operations rather than the about the relationship between the SCA model and the defined script interface. Not really deeply into this yet but a question to start with. Is there any way with the script container you are using of introspecting the methods that scripts provide? Simon
Re: Better support for dynamic language components
On 5/23/07, Simon Laws <[EMAIL PROTECTED]> wrote: Hi Just started looking at this in the context of bringing the aggregator sample to the Java runtime. I like the idea of having a dynamic interface as an option as it reduces the amount of configuration. The term dynamic term confused me to start with - I initially thought this was about constructing scripts with dynamic invocation style operations rather than the about the relationship between the SCA model and the defined script interface. Very open to alternative names, an 'any' interface was also suggested previously is that better? or something else? Not really deeply into this yet but a question to start with. Is there any way with the script container you are using of introspecting the methods that scripts provide? Not yet no, currently neither JSR-223 or BSF really provide any introspection capabilities. I'd like to get this capability added to BSF. We could do this on a language by language basis doing language specific things in Tuscany and eventually moving that to BSF, so if you have a specific language you'd like to get working with introspection go for it, and I'd be happy to help. One problem with introspection and dynamic languages is that as things can be handled dynamically at runtime there's not necessarily going to be anything there to introspect, so ideally most things should work without requiring introspection. The latest Groovy beta release now supports annotations, I'd really like to get that working with Tuscany so it supports the SCA annotations spec, we'd need introspection to support that. Probably be easiest to do this in a separate module (at least to start with), be a great thing to look at if anyone is interested in having a go. ...ant
