I've the same problem getting this to work with rhino which also needs the response class and i made a similar simple change to get it to work. The proper change you describe at the end sounds ok, one thing to consider is the new databinding framework and the IDL-independent ServiceContract/Operation models, so it probably shouldn't be using Class objects to represent the return type and only the actual extension impl should uses the Class.
...ant On 9/13/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
Hi Ant, I looked at the rhino implementation in the sandbox and tried doing the same for Ruby. There are some changes that were required to the 'easy' container framework :). Please let me know your thoughts on this:- - The function invocation APIs in JRuby require the 'returntype' class to be provided. As a result of this, I have had to modify the EasyInstance interface adding on more method (I did not delete the exsiting one to avoid confusions) - The EasyInvoker class also had to be changed to store the returnType and to accept this as an argument in its constructor - Finally the EasyComponent class had to be changed for the createTargetInvoker method to called the changed constructor of EasyInvoker. Ideally, I would like to exploit the responseClasses for this and get rid of all the changes that I have done as stated above. What is in my mind is as follows: - In the implementationLoader, after loading the componentType, get the list of service interfaces from the componentType. Then iterate thro all the service methods of each interface and store its return type into the responseClasses map. Set this map to the InstanceFactory instance that is anyways created in the implementationLoader. - For the keys to the responseClasses map, I plan to use the service method name and append a number that is equal to the number of arguments. i.e. for the method divide(arg1, arg2) the key would be 'divide_2'. I put this scheme in because at the time of invocation when I have to retrieve from the responseClasses map, I have only the operation name and the argument list with me. This I do with the assumption that overloading of service methods can be done only to the extent of varying the argument list length and will not be done varying the argument types, since Ruby is not statically typed. If this sounds sense to you, let me know and I will implement this way. I am attaching the source of whatever I have done, as a zip file in this mail just to give you better clarity. Thanks - Venkat On 9/13/06, ant elder <[EMAIL PROTECTED]> wrote: > > The problem with the generic script container which is using BSF is that > its > quite limited as to what it can do with introspection. For example, I'm > don't think it can get at the attr_writer variables in Ruby so it can't > support Ruby introspection the way the C++ Ruby container does, and > there's > probably similar problems with other languages. I also couldn't see how > to > get it to work with scopes properly without using a new BSFManager for > each > instance which means recompiling the script for each instance which is a > bit > inefficient. So at least for now I think it is useful to keep the > langauge > specific containers (i've just added a rhino one to the sandbox). > > What i'd like to do now is just implement a few containers and get > support > for all the things like scopes, lifecycle, async, properties and > references > working so we can clearly see what code can be made common. If you'd > like to > do Ruby or add support for something like async or component lifecylces > that > would be great. > > ...ant > > On 9/13/06, Venkata Krishnan <[EMAIL PROTECTED] > wrote: > > > > Hi Ant, > > > > Sequel to our last chat over IRC I took a look at your Sandbox. I am > able > > to understand all of what you have done there. A couple of thoughts / > > questions ... > > - So would it be that we just have this one 'ScriptContainer' that > will > > take > > care of javascript, ruby, groovy. > > - Would it be good to have a Script Registry (like the wsdl registry > and > > so > > on) that would have compiled scripts. So given a script source one > can > > get > > a BSFEngine from the registry. But then what about the context info > > (properties and references) - how do we set them in a 'flyweight' way? > > > - What do we do about introspectable component type info? Should we > have > > an > > interface for which we will have implementations for various script > types? > > > > Please let me know your thoughts on the next steps with the Sandbox > stuff > > and what I can help you out with? > > > > Thanks > > > > - Venkat > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
