Re: Refactoring commonality amongst Script containers in Java SCA
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
Re: Refactoring commonality amongst Script containers in Java SCA
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]
Re: Refactoring commonality amongst Script containers in Java SCA
I've added this ruby container to the sandbox now Venkat. I changed it to handle the response types the way i'd already done for the rhino container, not because that way is better just as i'd already done that for the other containers so it was easier than changing everything to the ruby way and as we need to completely redo that part anyway this way was easier to keep for now. ...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]
Re: Refactoring commonality amongst Script containers in Java SCA
Thanks Ant. No problems about the change.. I will lookup sometime to get to the same page. - Venkat On 9/14/06, ant elder <[EMAIL PROTECTED]> wrote: I've added this ruby container to the sandbox now Venkat. I changed it to handle the response types the way i'd already done for the rhino container, not because that way is better just as i'd already done that for the other containers so it was easier than changing everything to the ruby way and as we need to completely redo that part anyway this way was easier to keep for now. ...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 > > > > > > > > > > > > --
Re: Refactoring commonality amongst Script containers in Java SCA
This is all working quite well now so i'd like to move it from my sandbox to be with the other containers. BSF 2.4 has just come out and the jar is available from a proper maven repo and the script container supports all the SCA things like references, properties and async, also the start of a website page describing it which I'll move to the site once its a bit more done: https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/container.script/doc/sca-java-container-script.xml https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/container.script/ https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/container.easy/ ...ant 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 > >
Re: Refactoring commonality amongst Script containers in Java SCA
On Oct 7, 2006, at 7:22 AM, ant elder wrote: This is all working quite well now so i'd like to move it from my sandbox to be with the other containers. BSF 2.4 has just come out and the jar is available from a proper maven repo and the script container supports all the SCA things like references, properties and async, also the start of a website page describing it which I'll move to the site once its a bit more done: https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ container.script/doc/sca-java-container-script.xml https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ container.script/ https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ container.easy/ I'm fine with this as long as the name of "container.easy" can be changed to something that denotes it has to do with scripting, something like "container.bsf". Jim ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Refactoring commonality amongst Script containers in Java SCA
On Oct 7, 2006, at 10:42 AM, Jim Marino wrote: On Oct 7, 2006, at 7:22 AM, ant elder wrote: This is all working quite well now so i'd like to move it from my sandbox to be with the other containers. BSF 2.4 has just come out and the jar is available from a proper maven repo and the script container supports all the SCA things like references, properties and async, also the start of a website page describing it which I'll move to the site once its a bit more done: https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ container.script/doc/sca-java-container-script.xml https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ container.script/ https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ container.easy/ I'm fine with this as long as the name of "container.easy" can be changed to something that denotes it has to do with scripting, something like "container.bsf". After looking at the code more instead of having something separate, why wouldn't we look to see if we can merge the "easy container" into the extension API? I'd like to get a clearer direction on this before we move things around. Specifically, I have a few questions related to this: 1. Is this container just for scripting? It appears not to be tied to scripting 2. What value does this container provide over the extension API? Does it automate certain coding tasks only relevant to a subset of containers or all containers? Could we just merge such automation with AtomicComponentExtension 3. There appears to be a bit of code duplication, some of which may be a vestige from the Groovy container which needs to be refactored. For example, AsyncInvoker. In a merge, maybe we could eliminate the need for this? Jim Jim ...ant - 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]
Re: Refactoring commonality amongst Script containers in Java SCA
Hi Jim... Here is whatever I know of this... To start with, yes this is just for the script containers When we were doing the containers for scripting, we found that we were just copying a basic framework of common code across containers and then specializing parts that were very specific to the scripting language in question. For example the Javascript and Ruby containers will look just about the same but for the parts where the bridges - Rhino and JRuby come in. The specific parts typically come in where these bridges have to be invoked to compile the given script and create an instance of it, to transform data objects from Java to Script objects during function invocation. But for this, there is a whole lot of other things that are pretty much common which has been factored into 'easy'. This factoring is aimed only accelerate the development of a subset of containers - those that are related to scripting as they all share the common feature of having to specify the script, having to load and compile the script thro appropriate bridges and so on. I am not sure if this commonality is wide enough to be taken further up into AutomicComponentExtension level. Anyways will wait for Ant to bring in his view as the originator of this Thanks - Venkat Thanks - Venkat On 10/8/06, Jim Marino <[EMAIL PROTECTED]> wrote: On Oct 7, 2006, at 10:42 AM, Jim Marino wrote: > > On Oct 7, 2006, at 7:22 AM, ant elder wrote: > >> This is all working quite well now so i'd like to move it from my >> sandbox to >> be with the other containers. BSF 2.4 has just come out and the >> jar is >> available from a proper maven repo and the script container >> supports all the >> SCA things like references, properties and async, also the start of a >> website page describing it which I'll move to the site once its a >> bit more >> done: >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >> container.script/doc/sca-java-container-script.xml >> >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >> container.script/ >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >> container.easy/ >> > I'm fine with this as long as the name of "container.easy" can be > changed to something that denotes it has to do with scripting, > something like "container.bsf". > After looking at the code more instead of having something separate, why wouldn't we look to see if we can merge the "easy container" into the extension API? I'd like to get a clearer direction on this before we move things around. Specifically, I have a few questions related to this: 1. Is this container just for scripting? It appears not to be tied to scripting 2. What value does this container provide over the extension API? Does it automate certain coding tasks only relevant to a subset of containers or all containers? Could we just merge such automation with AtomicComponentExtension 3. There appears to be a bit of code duplication, some of which may be a vestige from the Groovy container which needs to be refactored. For example, AsyncInvoker. In a merge, maybe we could eliminate the need for this? Jim > Jim > >> ...ant > > > - > 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]
Re: Refactoring commonality amongst Script containers in Java SCA
On 10/7/06, Jim Marino <[EMAIL PROTECTED]> wrote: On Oct 7, 2006, at 10:42 AM, Jim Marino wrote: > > On Oct 7, 2006, at 7:22 AM, ant elder wrote: > >> This is all working quite well now so i'd like to move it from my >> sandbox to >> be with the other containers. BSF 2.4 has just come out and the >> jar is >> available from a proper maven repo and the script container >> supports all the >> SCA things like references, properties and async, also the start of a >> website page describing it which I'll move to the site once its a >> bit more >> done: >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >> container.script/doc/sca-java-container-script.xml >> >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >> container.script/ >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >> container.easy/ >> > I'm fine with this as long as the name of "container.easy" can be > changed to something that denotes it has to do with scripting, > something like "container.bsf". > After looking at the code more instead of having something separate, why wouldn't we look to see if we can merge the "easy container" into the extension API? I'd like to get a clearer direction on this before we move things around. Specifically, I have a few questions related to this: 1. Is this container just for scripting? It appears not to be tied to scripting 2. What value does this container provide over the extension API? Does it automate certain coding tasks only relevant to a subset of containers or all containers? Could we just merge such automation with AtomicComponentExtension 3. There appears to be a bit of code duplication, some of which may be a vestige from the Groovy container which needs to be refactored. For example, AsyncInvoker. In a merge, maybe we could eliminate the need for this? Jim Way back I was moaning about the complexity of the SPI and it was suggested having a separate extension project for a simplified SPI for extensions with simpler requirements. I can't find a link, maybe the 1st sandbox phone call or an old IRC chat? Thats where this came from. Its not quite finished yet, there's some parts that could be simplified further. I'd also like to do the same thing for bindings but haven't got to that yet. This is not necessarily tied to only scripting containers but thats all we've tried it with so far, and as Venkat suggests there likely is a bit more work required to make it more generally useful. There probably are some parts that could be moved to existing SPI classes, but there are also parts that may be a bit inflexible to be made part of the general extension SPI. As you point out the async bit does seem pretty isolated so that probably could be easily moved out. Given we're trying to get an M2 release out real soon I'm not sure about messing with the existing SPI classes now. How about for now moving the obvious bits like async out but keeping the rest in say a separate container.helperproject or in a separate SPI package like org.apache.tuscany.spi.extension.container? ...ant ...ant
Re: Refactoring commonality amongst Script containers in Java SCA
On Oct 9, 2006, at 3:42 AM, ant elder wrote: On 10/7/06, Jim Marino <[EMAIL PROTECTED]> wrote: On Oct 7, 2006, at 10:42 AM, Jim Marino wrote: > > On Oct 7, 2006, at 7:22 AM, ant elder wrote: > >> This is all working quite well now so i'd like to move it from my >> sandbox to >> be with the other containers. BSF 2.4 has just come out and the >> jar is >> available from a proper maven repo and the script container >> supports all the >> SCA things like references, properties and async, also the start of a >> website page describing it which I'll move to the site once its a >> bit more >> done: >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >> container.script/doc/sca-java-container-script.xml >> >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >> container.script/ >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >> container.easy/ >> > I'm fine with this as long as the name of "container.easy" can be > changed to something that denotes it has to do with scripting, > something like "container.bsf". > After looking at the code more instead of having something separate, why wouldn't we look to see if we can merge the "easy container" into the extension API? I'd like to get a clearer direction on this before we move things around. Specifically, I have a few questions related to this: 1. Is this container just for scripting? It appears not to be tied to scripting 2. What value does this container provide over the extension API? Does it automate certain coding tasks only relevant to a subset of containers or all containers? Could we just merge such automation with AtomicComponentExtension 3. There appears to be a bit of code duplication, some of which may be a vestige from the Groovy container which needs to be refactored. For example, AsyncInvoker. In a merge, maybe we could eliminate the need for this? Jim Way back I was moaning about the complexity of the SPI and it was suggested having a separate extension project for a simplified SPI for extensions with simpler requirements. Could you outline where you think core is too complex for "simple requirements"? I'd like to get an extension into core. What I specifically want to avoid is creating a parallel extension mechanism. I can't find a link, maybe the 1st sandbox phone call or an old IRC chat? Thats where this came from. Its not quite finished yet, there's some parts that could be simplified further. I'd also like to do the same thing for bindings but haven't got to that yet. This is not necessarily tied to only scripting containers but thats all we've tried it with so far, and as Venkat suggests there likely is a bit more work required to make it more generally useful. There probably are some parts that could be moved to existing SPI classes, but there are also parts that may be a bit inflexible to be made part of the general extension SPI. As you point out the async bit does seem pretty isolated so that probably could be easily moved out. Given we're trying to get an M2 release out real soon I'm not sure about messing with the existing SPI classes now. How about for now moving the obvious bits like async out but keeping the rest in say a separate container.helperproject or in a separate SPI package like org.apache.tuscany.spi.extension.container? What parts are you suggesting to move up? I definitely do not want to create another SPI package. Perhaps you could list the parts of the classes you would move into a helper library as well as the areas they are trying to simplify? This way we could decide whether the core spi can be simplified directly? To start with, I assume the following would not be included: - AsyncTargetInvoker - AsyncMonitor - EasyInstanceFactory since that can be done using an ObjectFactory Some specific questions I have are: - How are script scopes handled? I'm assuming we want to have the runtime manage statefull scripts, as we get that for free. - I also noticed the scope is set by default to Module. The default SCA Java is stateless. I agree module scope may be a better default but do you think we should be consistent with other SCA language specs here? - EasyComponentType encapsulates another ComponentType. I would have thought there would be an inheritance relationship. Was this because we need a specialization of ComponentType to be created by the generic side-file loader? If so, I think we should fix that in core. - More generally on component types, I haven't been following the PHP spec work but my understanding based on proposals from the people working on it to the assembly group is that the trend is to move away from having to author side-files and more towards code-level metadata and defaults. Would we want to emphasize that? Maybe you could ping Graham Charters who has been working on these issues? - Do scripts need to be defined by the Java idl or could I use WSDL or JSON
Re: Refactoring commonality amongst Script containers in Java SCA
I looked at this some more and I think we can make a change in core to support loading of custom component types. This will allow us to get rid of having to use encapsulation for component types. Also, the async invoker should move into an extension class in core. Finally, I think ObjectFactory can replace EasyInstanceFactory. Given this, the classes that remain are: - EasyComponent -EasyComponentBuilder -EasyImplementation -EasyImplementationBuilder - EasyInvoker Assuming we make the above mentioned change in core, most of the above code contains "template" code that would have to be integrated with container-specific code (e.g. handling of references). Given that, would it be better to just document these code snippets in the extension documentation as they are generally three-line statements? I may be missing some extra functionality so please let me know. Jim On Oct 9, 2006, at 11:47 AM, Jim Marino wrote: On Oct 9, 2006, at 3:42 AM, ant elder wrote: On 10/7/06, Jim Marino <[EMAIL PROTECTED]> wrote: On Oct 7, 2006, at 10:42 AM, Jim Marino wrote: > > On Oct 7, 2006, at 7:22 AM, ant elder wrote: > >> This is all working quite well now so i'd like to move it from my >> sandbox to >> be with the other containers. BSF 2.4 has just come out and the >> jar is >> available from a proper maven repo and the script container >> supports all the >> SCA things like references, properties and async, also the start of a >> website page describing it which I'll move to the site once its a >> bit more >> done: >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >> container.script/doc/sca-java-container-script.xml >> >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >> container.script/ >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >> container.easy/ >> > I'm fine with this as long as the name of "container.easy" can be > changed to something that denotes it has to do with scripting, > something like "container.bsf". > After looking at the code more instead of having something separate, why wouldn't we look to see if we can merge the "easy container" into the extension API? I'd like to get a clearer direction on this before we move things around. Specifically, I have a few questions related to this: 1. Is this container just for scripting? It appears not to be tied to scripting 2. What value does this container provide over the extension API? Does it automate certain coding tasks only relevant to a subset of containers or all containers? Could we just merge such automation with AtomicComponentExtension 3. There appears to be a bit of code duplication, some of which may be a vestige from the Groovy container which needs to be refactored. For example, AsyncInvoker. In a merge, maybe we could eliminate the need for this? Jim Way back I was moaning about the complexity of the SPI and it was suggested having a separate extension project for a simplified SPI for extensions with simpler requirements. Could you outline where you think core is too complex for "simple requirements"? I'd like to get an extension into core. What I specifically want to avoid is creating a parallel extension mechanism. I can't find a link, maybe the 1st sandbox phone call or an old IRC chat? Thats where this came from. Its not quite finished yet, there's some parts that could be simplified further. I'd also like to do the same thing for bindings but haven't got to that yet. This is not necessarily tied to only scripting containers but thats all we've tried it with so far, and as Venkat suggests there likely is a bit more work required to make it more generally useful. There probably are some parts that could be moved to existing SPI classes, but there are also parts that may be a bit inflexible to be made part of the general extension SPI. As you point out the async bit does seem pretty isolated so that probably could be easily moved out. Given we're trying to get an M2 release out real soon I'm not sure about messing with the existing SPI classes now. How about for now moving the obvious bits like async out but keeping the rest in say a separate container.helperproject or in a separate SPI package like org.apache.tuscany.spi.extension.container? What parts are you suggesting to move up? I definitely do not want to create another SPI package. Perhaps you could list the parts of the classes you would move into a helper library as well as the areas they are trying to simplify? This way we could decide whether the core spi can be simplified directly? To start with, I assume the following would not be included: - AsyncTargetInvoker - AsyncMonitor - EasyInstanceFactory since that can be done using an ObjectFactory Some specific questions I have are: - How are script scopes handled? I'm assuming we want to have the runtime manage statefull scripts, as we get that for free. - I also noticed the scope i
Re: Refactoring commonality amongst Script containers in Java SCA
I'd be really happy for all those to become part of the core, but I'm not sure I see how all that remains will be a few three-line statements. How about I move this to a container-helper as I suggested before, we pull all the bits out and do the refactoring and before we cut M2 see whats left and if there really is nothing much left just doc it otherwise re-evaluate then what to do with what remains? ...ant On 10/10/06, Jim Marino <[EMAIL PROTECTED]> wrote: I looked at this some more and I think we can make a change in core to support loading of custom component types. This will allow us to get rid of having to use encapsulation for component types. Also, the async invoker should move into an extension class in core. Finally, I think ObjectFactory can replace EasyInstanceFactory. Given this, the classes that remain are: - EasyComponent -EasyComponentBuilder -EasyImplementation -EasyImplementationBuilder - EasyInvoker Assuming we make the above mentioned change in core, most of the above code contains "template" code that would have to be integrated with container-specific code (e.g. handling of references). Given that, would it be better to just document these code snippets in the extension documentation as they are generally three-line statements? I may be missing some extra functionality so please let me know. Jim On Oct 9, 2006, at 11:47 AM, Jim Marino wrote: > > On Oct 9, 2006, at 3:42 AM, ant elder wrote: > >> On 10/7/06, Jim Marino <[EMAIL PROTECTED]> wrote: >>> >>> >>> On Oct 7, 2006, at 10:42 AM, Jim Marino wrote: >>> >>> > >>> > On Oct 7, 2006, at 7:22 AM, ant elder wrote: >>> > >>> >> This is all working quite well now so i'd like to move it from my >>> >> sandbox to >>> >> be with the other containers. BSF 2.4 has just come out and the >>> >> jar is >>> >> available from a proper maven repo and the script container >>> >> supports all the >>> >> SCA things like references, properties and async, also the >>> start of a >>> >> website page describing it which I'll move to the site once its a >>> >> bit more >>> >> done: >>> >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >>> >> container.script/doc/sca-java-container-script.xml >>> >> >>> >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >>> >> container.script/ >>> >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ >>> >> container.easy/ >>> >> >>> > I'm fine with this as long as the name of "container.easy" can be >>> > changed to something that denotes it has to do with scripting, >>> > something like "container.bsf". >>> > >>> After looking at the code more instead of having something separate, >>> why wouldn't we look to see if we can merge the "easy container" >>> into >>> the extension API? I'd like to get a clearer direction on this >>> before >>> we move things around. >>> >>> Specifically, I have a few questions related to this: >>> >>> 1. Is this container just for scripting? It appears not to be >>> tied to >>> scripting >>> 2. What value does this container provide over the extension API? >>> Does it automate certain coding tasks only relevant to a subset of >>> containers or all containers? Could we just merge such automation >>> with AtomicComponentExtension >>> 3. There appears to be a bit of code duplication, some of which may >>> be a vestige from the Groovy container which needs to be refactored. >>> For example, AsyncInvoker. In a merge, maybe we could eliminate the >>> need for this? >>> >>> Jim >> >> >> Way back I was moaning about the complexity of the SPI and it was >> suggested >> having a separate extension project for a simplified SPI for >> extensions with >> simpler requirements. > Could you outline where you think core is too complex for "simple > requirements"? I'd like to get an extension into core. What I > specifically want to avoid is creating a parallel extension mechanism. >> I can't find a link, maybe the 1st sandbox phone call >> or an old IRC chat? Thats where this came from. Its not quite >> finished yet, >> there's some parts that could be simplified further. I'd also like >> to do the >> same thing for bindings but haven't got to that yet. This is not >> necessarily >> tied to only scripting containers but thats all we've tried it >> with so far, >> and as Venkat suggests there likely is a bit more work required to >> make it >> more generally useful. There probably are some parts that could be >> moved to >> existing SPI classes, but there are also parts that may be a bit >> inflexible >> to be made part of the general extension SPI. As you point out the >> async bit >> does seem pretty isolated so that probably could be easily moved >> out. Given >> we're trying to get an M2 release out real soon I'm not sure about >> messing >> with the existing SPI classes now. How about for now moving the >> obvious bits >> like async out but keeping the rest in say a separate >> container.helperproject or in a separate SPI package like >> org.apache.tu
Re: Refactoring commonality amongst Script containers in Java SCA
On Oct 10, 2006, at 7:53 AM, ant elder wrote: I'd be really happy for all those to become part of the core, but I'm not sure I see how all that remains will be a few three-line statements. How about I move this to a container-helper as I suggested before, we pull all the bits out and do the refactoring and before we cut M2 see whats left and if there really is nothing much left just doc it otherwise re- evaluate then what to do with what remains? I took a closer look at the ComponentType encapsulation problem. The problem resides in the fact that the generic component type element loader creates a generic component type as the component type side file is processed. What should happen is that the component type should be created by the implementation loader (e.g. PojoComponentType, or maybe ScriptComponentType) and passed into the loader. The load method on StAXElementLoader would need to be changed to: load(CompositeComponent parent, ModelObject object, XMLStreamReader reader, DeploymentContext deploymentContext) would Where "object" was a model object the loader would populate or null, in which case the loader would be responsible for creating one. In the case of custom component types, the implementation loader would create a subclass of ComponentType and pass it back into the loader registry. A script component type loader would then be responsible for introspecting the custom component type side file. Without this, we can't properly support scopes in side files so I'd like to get this fix in. In addition, I'd like to get duplicate code taken care of (AsyncTargetInvoker, EasyInstanceFactory). I'm willing to take this on and help out since I think this is important we clear up. Also, I still believe once we take care of these issues we probably won't need a separate extension library. One issue is this does affect the SPI and I think we need to assess the risk of these changes on getting the release out. If people are o.k. with me doing these changes, I'll jump in and make them. If it poses too much risk, I suggest we consider branching. Thoughts? Jim ...ant On 10/10/06, Jim Marino <[EMAIL PROTECTED]> wrote: I looked at this some more and I think we can make a change in core to support loading of custom component types. This will allow us to get rid of having to use encapsulation for component types. Also, the async invoker should move into an extension class in core. Finally, I think ObjectFactory can replace EasyInstanceFactory. Given this, the classes that remain are: - EasyComponent -EasyComponentBuilder -EasyImplementation -EasyImplementationBuilder - EasyInvoker Assuming we make the above mentioned change in core, most of the above code contains "template" code that would have to be integrated with container-specific code (e.g. handling of references). Given that, would it be better to just document these code snippets in the extension documentation as they are generally three-line statements? I may be missing some extra functionality so please let me know. Jim On Oct 9, 2006, at 11:47 AM, Jim Marino wrote: > > On Oct 9, 2006, at 3:42 AM, ant elder wrote: > >> On 10/7/06, Jim Marino <[EMAIL PROTECTED]> wrote: >>> >>> >>> On Oct 7, 2006, at 10:42 AM, Jim Marino wrote: >>> >>> > >>> > On Oct 7, 2006, at 7:22 AM, ant elder wrote: >>> > >>> >> This is all working quite well now so i'd like to move it from my >>> >> sandbox to >>> >> be with the other containers. BSF 2.4 has just come out and the >>> >> jar is >>> >> available from a proper maven repo and the script container >>> >> supports all the >>> >> SCA things like references, properties and async, also the >>> start of a >>> >> website page describing it which I'll move to the site once its a >>> >> bit more >>> >> done: >>> >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ ant/ >>> >> container.script/doc/sca-java-container-script.xml >>> >> >>> >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ ant/ >>> >> container.script/ >>> >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ ant/ >>> >> container.easy/ >>> >> >>> > I'm fine with this as long as the name of "container.easy" can be >>> > changed to something that denotes it has to do with scripting, >>> > something like "container.bsf". >>> > >>> After looking at the code more instead of having something separate, >>> why wouldn't we look to see if we can merge the "easy container" >>> into >>> the extension API? I'd like to get a clearer direction on this >>> before >>> we move things around. >>> >>> Specifically, I have a few questions related to this: >>> >>> 1. Is this container just for scripting? It appears not to be >>> tied to >>> scripting >>> 2. What value does this container provide over the extension API? >>> Does it automate certain coding tasks only relevant to a subset of >>> containers or all containers? Could we just merge such automatio
Re: Refactoring commonality amongst Script containers in Java SCA
Hi, A few comments inline Thanks - Venkat On 10/11/06, Jim Marino <[EMAIL PROTECTED]> wrote: On Oct 10, 2006, at 7:53 AM, ant elder wrote: > I'd be really happy for all those to become part of the core, but > I'm not > sure I see how all that remains will be a few three-line > statements. How > about I move this to a container-helper as I suggested before, we > pull all > the bits out and do the refactoring and before we cut M2 see whats > left and > if there really is nothing much left just doc it otherwise re- > evaluate then > what to do with what remains? I took a closer look at the ComponentType encapsulation problem. The problem resides in the fact that the generic component type element loader creates a generic component type as the component type side file is processed. What should happen is that the component type should be created by the implementation loader (e.g. PojoComponentType, or maybe ScriptComponentType) and passed into the loader. The load method on StAXElementLoader would need to be changed to: load(CompositeComponent parent, ModelObject object, XMLStreamReader reader, DeploymentContext deploymentContext) would Where "object" was a model object the loader would populate or null, in which case the loader would be responsible for creating one. +1. So when object is null there simply no specialized component type and just the base would do. Right ? In the case of custom component types, the implementation loader would create a subclass of ComponentType and pass it back into the loader registry. A script component type loader would then be responsible for introspecting the custom component type side file. Here again is there a way where the custom component type loaders are only called for extensions i.e. only for those elements that are not known to the base ComponentType. This way we can avoid duplication of how the common stuff of properties / references / services get loaded. Am I off track ? Without this, we can't properly support scopes in side files so I'd like to get this fix in. Not only for the scopes. We are not able to get the basic sidefile stuff up in Pojo - meaning today if we wanted to try out Pojo implementation of a component with side files, we will end up in exceptions. In addition, I'd like to get duplicate code taken care of (AsyncTargetInvoker, EasyInstanceFactory). I'm willing to take this on and help out since I think this is important we clear up. Also, I still believe once we take care of these issues we probably won't need a separate extension library. One issue is this does affect the SPI and I think we need to assess the risk of these changes on getting the release out. If people are o.k. with me doing these changes, I'll jump in and make them. If it poses too much risk, I suggest we consider branching. Thoughts? Jim > > ...ant > > On 10/10/06, Jim Marino <[EMAIL PROTECTED]> wrote: >> >> I looked at this some more and I think we can make a change in core >> to support loading of custom component types. This will allow us to >> get rid of having to use encapsulation for component types. Also, the >> async invoker should move into an extension class in core. Finally, I >> think ObjectFactory can replace EasyInstanceFactory. Given this, the >> classes that remain are: >> - EasyComponent >> -EasyComponentBuilder >> -EasyImplementation >> -EasyImplementationBuilder >> - EasyInvoker >> >> Assuming we make the above mentioned change in core, most of the >> above code contains "template" code that would have to be integrated >> with container-specific code (e.g. handling of references). Given >> that, would it be better to just document these code snippets in the >> extension documentation as they are generally three-line statements? >> I may be missing some extra functionality so please let me know. >> >> Jim >> >> >> On Oct 9, 2006, at 11:47 AM, Jim Marino wrote: >> >> > >> > On Oct 9, 2006, at 3:42 AM, ant elder wrote: >> > >> >> On 10/7/06, Jim Marino <[EMAIL PROTECTED]> wrote: >> >>> >> >>> >> >>> On Oct 7, 2006, at 10:42 AM, Jim Marino wrote: >> >>> >> >>> > >> >>> > On Oct 7, 2006, at 7:22 AM, ant elder wrote: >> >>> > >> >>> >> This is all working quite well now so i'd like to move it >> from my >> >>> >> sandbox to >> >>> >> be with the other containers. BSF 2.4 has just come out and >> the >> >>> >> jar is >> >>> >> available from a proper maven repo and the script container >> >>> >> supports all the >> >>> >> SCA things like references, properties and async, also the >> >>> start of a >> >>> >> website page describing it which I'll move to the site once >> its a >> >>> >> bit more >> >>> >> done: >> >>> >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ >> ant/ >> >>> >> container.script/doc/sca-java-container-script.xml >> >>> >> >> >>> >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ >> ant/ >> >>> >> container.script/ >> >>> >> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ >> a
Re: Refactoring commonality amongst Script containers in Java SCA
I took a closer look at the ComponentType encapsulation problem. The problem resides in the fact that the generic component type element loader creates a generic component type as the component type side file is processed. What should happen is that the component type should be created by the implementation loader (e.g. PojoComponentType, or maybe ScriptComponentType) and passed into the loader. The load method on StAXElementLoader would need to be changed to: load(CompositeComponent parent, ModelObject object, XMLStreamReader reader, DeploymentContext deploymentContext) would Where "object" was a model object the loader would populate or null, in which case the loader would be responsible for creating one. +1. So when object is null there simply no specialized component type and just the base would do. Right ? Yep In the case of custom component types, the implementation loader would create a subclass of ComponentType and pass it back into the loader registry. A script component type loader would then be responsible for introspecting the custom component type side file. Here again is there a way where the custom component type loaders are only called for extensions i.e. only for those elements that are not known to the base ComponentType. This way we can avoid duplication of how the common stuff of properties / references / services get loaded. Am I off track ? I don't quite follow, can you point me to code that illustrates the problem? AtomicComponent implementations always need to deal with wires and properties being handed to them by the wiring fabric as they need to choose an injection implementation strategy. Without this, we can't properly support scopes in side files so I'd like to get this fix in. Not only for the scopes. We are not able to get the basic sidefile stuff up in Pojo - meaning today if we wanted to try out Pojo implementation of a component with side files, we will end up in exceptions. Yes componentType side files are broken for POJOs as well but the fix I outlined will address that as well - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Refactoring commonality amongst Script containers in Java SCA
This is ending up all talk and no action so I'm going to again suggest just moving it now, pulling the bits into core as discussed and you've said you'll help with, and then seeing whats left and decide what to do with that then. ...ant On 10/11/06, Jim Marino <[EMAIL PROTECTED]> wrote: >> I took a closer look at the ComponentType encapsulation problem. The >> problem resides in the fact that the generic component type element >> loader creates a generic component type as the component type side >> file is processed. What should happen is that the component type >> should be created by the implementation loader (e.g. >> PojoComponentType, or maybe ScriptComponentType) and passed into the >> loader. The load method on StAXElementLoader would need to be changed >> to: >> >> load(CompositeComponent parent, ModelObject object, XMLStreamReader >> reader, DeploymentContext deploymentContext) would >> >> Where "object" was a model object the loader would populate or null, >> in which case the loader would be responsible for creating one. > > > +1. So when object is null there simply no specialized component > type and > just the base would do. Right ? > Yep > In >> the case of custom component types, the implementation loader would >> create a subclass of ComponentType and pass it back into the loader >> registry. A script component type loader would then be responsible >> for introspecting the custom component type side file. > > > Here again is there a way where the custom component type loaders > are only > called for extensions i.e. only for those elements that are not > known to the > base ComponentType. This way we can avoid duplication of how the > common > stuff of properties / references / services get loaded. Am I off > track ? > I don't quite follow, can you point me to code that illustrates the problem? AtomicComponent implementations always need to deal with wires and properties being handed to them by the wiring fabric as they need to choose an injection implementation strategy. > Without this, we can't properly support scopes in side files so I'd >> like to get this fix in. > > Not only for the scopes. We are not able to get the basic sidefile > stuff up > in Pojo - meaning today if we wanted to try out Pojo implementation > of a > component with side files, we will end up in exceptions. Yes componentType side files are broken for POJOs as well but the fix I outlined will address that as well - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Refactoring commonality amongst Script containers in Java SCA
On Oct 11, 2006, at 6:00 AM, ant elder wrote: This is ending up all talk and no action I don't see it that way. I think we are trying to arrive at the right thing to do...I've asked specific questions that I'd like to get answers to before I feel comfortable moving this out of the sandbox. I'll list them again here, and perhaps you could respond inline? Based on my current understanding of the code, I have also outlined the path I think we should take for incorporating this into core. - How are script scopes handled? I'm assuming we want to have the runtime manage statefull scripts, as we get that for free. - I also noticed the scope is set by default to Module. The default SCA Java is stateless. I agree module scope may be a better default but do you think we should be consistent with other SCA language specs here? - More generally on component types, I haven't been following the PHP spec work but my understanding based on proposals from the people working on it to the assembly group is that the trend is to move away from having to author side-files and more towards code-level metadata and defaults. Would we want to emphasize that? Maybe you could ping Graham Charters who has been working on these issues? - Do scripts need to be defined by the Java idl or could I use WSDL or JSON or something else (assuming the proper extension)? - What does EasyInstanceFactory.getResponseClasses(List services) do? - How are references handled? Can they be injected onto fields in prototype-based languages? - What value does this container provide over the extension API? Does it automate certain coding tasks only relevant to a subset of containers or all containers? Could we just merge such automation with AtomicComponentExtension Based on my current understanding, my recommendation would be to do the following: 1. AsyncInvoker.java - Script containers should extend from an SPI class 2. AsyncMonitor.java - Script containers should define their own logging interface. Having one interface with no implementation seems valueless 3. EasyComponent.java - I believe this to be adding a "context" object for references and properties. How does this play with a scripting programming model that uses DI? My recommendation would be to document this as an implementation pattern 4. EasyComponentBuilder.java - Ditto from EasyComponent 5. EasyComponentType.java - I'd like to fix the core component loading problem. I think we can also move the lifecycle scope method to ComponentType (also moving it from PojoComponentType) 6. EasyComponentTypeLoader.java - If do change 5, we don't need this anymore 7. EasyInstanceFactory.java - Should be replaced by ObjectFactory from SPI 8. EasyImplementation.java - If we do change 7, I don't think we need this. Each implementation type should define their own model object anyway so we can track types during the build phase (this is important). Having a generic implementation representation with no specialization will occlude specifics related to types. 9. EasyImplementationLoader.java - Ditto for the above 10. EasyInstance.java - I'm not sure if this is needed anymore. The operations which may be done on a script instance seem specific to the script type to me 11. EasyInvoker.java - I'm also not sure if this is needed anymore. So, based on this, I would: 1. Fix AsyncInvoker 2. Modify the ComponentType signature to include lifecycle scope 3. Fix the component type loading problem I believe that would be the best way to get this moved out of the sandbox. Based on the answers to the questions above, I may be missing something and we can revist. I'm happy to volunteer and do the work. What do you think? Jim so I'm going to again suggest just moving it now, pulling the bits into core as discussed and you've said you'll help with, and then seeing whats left and decide what to do with that then. ...ant On 10/11/06, Jim Marino <[EMAIL PROTECTED]> wrote: >> I took a closer look at the ComponentType encapsulation problem. The >> problem resides in the fact that the generic component type element >> loader creates a generic component type as the component type side >> file is processed. What should happen is that the component type >> should be created by the implementation loader (e.g. >> PojoComponentType, or maybe ScriptComponentType) and passed into the >> loader. The load method on StAXElementLoader would need to be changed >> to: >> >> load(CompositeComponent parent, ModelObject object, XMLStreamReader >> reader, DeploymentContext deploymentContext) would >> >> Where "object" was a model object the loader would populate or null, >> in which case the loader would be responsible for creating one. > > > +1. So when object is null there simply no specialized component > type and > just the base would do. Right ? > Yep > In >> the cas
Re: Refactoring commonality amongst Script containers in Java SCA
On 10/10/06, Jim Marino <[EMAIL PROTECTED]> wrote: On Oct 10, 2006, at 7:53 AM, ant elder wrote: > I'd be really happy for all those to become part of the core, but > I'm not > sure I see how all that remains will be a few three-line > statements. How > about I move this to a container-helper as I suggested before, we > pull all > the bits out and do the refactoring and before we cut M2 see whats > left and > if there really is nothing much left just doc it otherwise re- > evaluate then > what to do with what remains? I took a closer look at the ComponentType encapsulation problem. The problem resides in the fact that the generic component type element loader creates a generic component type as the component type side file is processed. What should happen is that the component type should be created by the implementation loader (e.g. PojoComponentType, or maybe ScriptComponentType) and passed into the loader. The load method on StAXElementLoader would need to be changed to: load(CompositeComponent parent, ModelObject object, XMLStreamReader reader, DeploymentContext deploymentContext) would Where "object" was a model object the loader would populate or null, in which case the loader would be responsible for creating one. In the case of custom component types, the implementation loader would create a subclass of ComponentType and pass it back into the loader registry. A script component type loader would then be responsible for introspecting the custom component type side file. Without this, we can't properly support scopes in side files so I'd like to get this fix in. In addition, I'd like to get duplicate code taken care of (AsyncTargetInvoker, EasyInstanceFactory). I'm willing to take this on and help out since I think this is important we clear up. Also, I still believe once we take care of these issues we probably won't need a separate extension library. One issue is this does affect the SPI and I think we need to assess the risk of these changes on getting the release out. If people are o.k. with me doing these changes, I'll jump in and make them. If it poses too much risk, I suggest we consider branching. Thoughts? Jim As you don't like the easy SPI extension I've got rid of the easy extension dependency of the script container. I've moved the script container into trunk as it was going stale and i want to start using and improving it. It still uses some of the easy classes which are in a helper package now, i'll get rid of them as we clean things up. I saw you've done some core changes for the componentType problem, thanks, I'll go look at how to use that for this (and the other script containers) and change the code as appropriate. You said you'd take on getting the things like the async code into the spi to avoid all that duplicate code so would you like to go ahead and do that now? (or I can do it if you like). Once the componentType and async changes are done I/we can look at the next things to simplify and once all that refactoring is done I'll look at what remains in the helper package and see if there are still things I think could be simplified. ...ant
Re: Refactoring commonality amongst Script containers in Java SCA
Comments in line... ...ant On 10/11/06, Jim Marino <[EMAIL PROTECTED]> wrote: - How are script scopes handled? I'm assuming we want to have the runtime manage statefull scripts, as we get that for free. agree - I also noticed the scope is set by default to Module. The default SCA Java is stateless. I agree module scope may be a better default but do you think we should be consistent with other SCA language specs here? AFAICT most people think module is a better default and I think thats especially so for scripting languages, so while there is no spec for scripting languages I'd prefer to use a default that works well with them. Maybe the Java spec people should revisit the decision to use stateless as their default? - More generally on component types, I haven't been following the PHP spec work but my understanding based on proposals from the people working on it to the assembly group is that the trend is to move away from having to author side-files and more towards code-level metadata and defaults. Would we want to emphasize that? Yes definitely! If you trawl back through the archives we've already discussed doing this, its something I think is really important to get done. Wasn't possible in the M2 time frame unfortunately , I'm planning on trying to get it done for M3. - Do scripts need to be defined by the Java idl or could I use WSDL or JSON or something else (assuming the proper extension)? They shouldn't be restricted to Java IDL, WSDL works as well, eg with JavaScript/E4X, and I mentioned a while back wanting an SMD IDL for JSON and JavaScript but that was before we had the IDL extension story sortted out - another thing for M3. - What does EasyInstanceFactory.getResponseClasses(List services) do? It was so the response from a script call which may be of unknown type can be coerced to the expected type. Now that we have the databinding framework this needs to be revisited as part of the larger work of integrating the databinding framework with the script language containers. - How are references handled? Can they be injected onto fields in prototype-based languages? Not presently for JavaScript (not sure about Ruby, Venkat?) and it wont be possible with the script container using BSF for JavaScript either due to a limitation with the bsf engine. Thats fixed in BSF v3 though which is another thing I would like to look at in M3. ...ant
Re: Refactoring commonality amongst Script containers in Java SCA
As you don't like the easy SPI extension I've got rid of the easy extension dependency of the script container. I've moved the script container into trunk as it was going stale and i want to start using and improving it. It still uses some of the easy classes which are in a helper package now, i'll get rid of them as we clean things up. I saw you've done some core changes for the componentType problem, thanks, I'll go look at how to use that for this (and the other script containers) and change the code as appropriate. You said you'd take on getting the things like the async code into the spi to avoid all that duplicate code so would you like to go ahead and do that now? (or I can do it if you like). O.K. I committed the changes. There is no need to handle message id correlation as the wiring fabric (specifically TargetInvokerExtension) does it automatically. You should be able to delete AsyncMonitor and the async target invoker. You will also need to change some of the signatures of the builders to pass in a WorkContext and ExectionMonitor (these are autowired to ComponentBuilderExtension). I made some basic changes the the script container to pass tests but you will probably need to do some more (limited) refactoring to get it fully operational. I fixed the Groovy container so you can use that as an example. (BTW, as a side note, container.script is not part of the build by default). The other changes to make are to create a script specialization of ComponentType in the loader and use ObjectFactory for creating instances. Once the componentType and async changes are done I/we can look at the next things to simplify and once all that refactoring is done I'll look at what remains in the helper package and see if there are still things I think could be simplified. If you can make those changes, we can take another pass over the helper classes and see what is left. Jim ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Refactoring commonality amongst Script containers in Java SCA
On Oct 25, 2006, at 8:02 AM, ant elder wrote: Comments in line... ...ant On 10/11/06, Jim Marino <[EMAIL PROTECTED]> wrote: - How are script scopes handled? I'm assuming we want to have the runtime manage statefull scripts, as we get that for free. agree - I also noticed the scope is set by default to Module. The default SCA Java is stateless. I agree module scope may be a better default but do you think we should be consistent with other SCA language specs here? AFAICT most people think module is a better default and I think thats especially so for scripting languages, so while there is no spec for scripting languages I'd prefer to use a default that works well with them. Maybe the Java spec people should revisit the decision to use stateless as their default? I've made this argument on several occasions to the spec group but I haven't been successful in convincing people. I'll give it another try though since I agree module scope is a better default (interestingly in Srping the "singleton" equivalent is the default). - More generally on component types, I haven't been following the PHP spec work but my understanding based on proposals from the people working on it to the assembly group is that the trend is to move away from having to author side-files and more towards code-level metadata and defaults. Would we want to emphasize that? Yes definitely! If you trawl back through the archives we've already discussed doing this, its something I think is really important to get done. Wasn't possible in the M2 time frame unfortunately , I'm planning on trying to get it done for M3. - Do scripts need to be defined by the Java idl or could I use WSDL or JSON or something else (assuming the proper extension)? They shouldn't be restricted to Java IDL, WSDL works as well, eg with JavaScript/E4X, and I mentioned a while back wanting an SMD IDL for JSON and JavaScript but that was before we had the IDL extension story sortted out - another thing for M3. JSON would be interesting. - What does EasyInstanceFactory.getResponseClasses(List services) do? It was so the response from a script call which may be of unknown type can be coerced to the expected type. Now that we have the databinding framework this needs to be revisited as part of the larger work of integrating the databinding framework with the script language containers. Ah ok - How are references handled? Can they be injected onto fields in prototype-based languages? Not presently for JavaScript (not sure about Ruby, Venkat?) and it wont be possible with the script container using BSF for JavaScript either due to a limitation with the bsf engine. Thats fixed in BSF v3 though which is another thing I would like to look at in M3. I think that would be good to do. Jim ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Refactoring commonality amongst Script containers in Java SCA
Any luck in making these changes? Jim On Oct 26, 2006, at 8:30 AM, Jim Marino wrote: As you don't like the easy SPI extension I've got rid of the easy extension dependency of the script container. I've moved the script container into trunk as it was going stale and i want to start using and improving it. It still uses some of the easy classes which are in a helper package now, i'll get rid of them as we clean things up. I saw you've done some core changes for the componentType problem, thanks, I'll go look at how to use that for this (and the other script containers) and change the code as appropriate. You said you'd take on getting the things like the async code into the spi to avoid all that duplicate code so would you like to go ahead and do that now? (or I can do it if you like). O.K. I committed the changes. There is no need to handle message id correlation as the wiring fabric (specifically TargetInvokerExtension) does it automatically. You should be able to delete AsyncMonitor and the async target invoker. You will also need to change some of the signatures of the builders to pass in a WorkContext and ExectionMonitor (these are autowired to ComponentBuilderExtension). I made some basic changes the the script container to pass tests but you will probably need to do some more (limited) refactoring to get it fully operational. I fixed the Groovy container so you can use that as an example. (BTW, as a side note, container.script is not part of the build by default). The other changes to make are to create a script specialization of ComponentType in the loader and use ObjectFactory for creating instances. Once the componentType and async changes are done I/we can look at the next things to simplify and once all that refactoring is done I'll look at what remains in the helper package and see if there are still things I think could be simplified. If you can make those changes, we can take another pass over the helper classes and see what is left. Jim ...ant - 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]
Re: Refactoring commonality amongst Script containers in Java SCA
No, tied up on M2 things, i doubt I'll have time for this till M2 is done. ...ant On 10/31/06, Jim Marino <[EMAIL PROTECTED]> wrote: Any luck in making these changes? Jim On Oct 26, 2006, at 8:30 AM, Jim Marino wrote: >> >> >> As you don't like the easy SPI extension I've got rid of the easy >> extension >> dependency of the script container. I've moved the script >> container into >> trunk as it was going stale and i want to start using and >> improving it. It >> still uses some of the easy classes which are in a helper package >> now, i'll >> get rid of them as we clean things up. I saw you've done some core >> changes >> for the componentType problem, thanks, I'll go look at how to use >> that for >> this (and the other script containers) and change the code as >> appropriate. >> You said you'd take on getting the things like the async code into >> the spi >> to avoid all that duplicate code so would you like to go ahead and >> do that >> now? (or I can do it if you like). > O.K. I committed the changes. There is no need to handle message id > correlation as the wiring fabric (specifically > TargetInvokerExtension) does it automatically. You should be able > to delete AsyncMonitor and the async target invoker. You will also > need to change some of the signatures of the builders to pass in a > WorkContext and ExectionMonitor (these are autowired to > ComponentBuilderExtension). I made some basic changes the the > script container to pass tests but you will probably need to do > some more (limited) refactoring to get it fully operational. I > fixed the Groovy container so you can use that as an example. (BTW, > as a side note, container.script is not part of the build by default). > > The other changes to make are to create a script specialization of > ComponentType in the loader and use ObjectFactory for creating > instances. > >> Once the componentType and async changes >> are done I/we can look at the next things to simplify and once all >> that >> refactoring is done I'll look at what remains in the helper >> package and see >> if there are still things I think could be simplified. >> > If you can make those changes, we can take another pass over the > helper classes and see what is left. > > Jim > >> ...ant > > > - > 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]
Re: Refactoring commonality amongst Script containers in Java SCA
So do you mind if I make the changes? Jim On Oct 31, 2006, at 1:02 AM, ant elder wrote: No, tied up on M2 things, i doubt I'll have time for this till M2 is done. ...ant On 10/31/06, Jim Marino <[EMAIL PROTECTED]> wrote: Any luck in making these changes? Jim On Oct 26, 2006, at 8:30 AM, Jim Marino wrote: >> >> >> As you don't like the easy SPI extension I've got rid of the easy >> extension >> dependency of the script container. I've moved the script >> container into >> trunk as it was going stale and i want to start using and >> improving it. It >> still uses some of the easy classes which are in a helper package >> now, i'll >> get rid of them as we clean things up. I saw you've done some core >> changes >> for the componentType problem, thanks, I'll go look at how to use >> that for >> this (and the other script containers) and change the code as >> appropriate. >> You said you'd take on getting the things like the async code into >> the spi >> to avoid all that duplicate code so would you like to go ahead and >> do that >> now? (or I can do it if you like). > O.K. I committed the changes. There is no need to handle message id > correlation as the wiring fabric (specifically > TargetInvokerExtension) does it automatically. You should be able > to delete AsyncMonitor and the async target invoker. You will also > need to change some of the signatures of the builders to pass in a > WorkContext and ExectionMonitor (these are autowired to > ComponentBuilderExtension). I made some basic changes the the > script container to pass tests but you will probably need to do > some more (limited) refactoring to get it fully operational. I > fixed the Groovy container so you can use that as an example. (BTW, > as a side note, container.script is not part of the build by default). > > The other changes to make are to create a script specialization of > ComponentType in the loader and use ObjectFactory for creating > instances. > >> Once the componentType and async changes >> are done I/we can look at the next things to simplify and once all >> that >> refactoring is done I'll look at what remains in the helper >> package and see >> if there are still things I think could be simplified. >> > If you can make those changes, we can take another pass over the > helper classes and see what is left. > > Jim > >> ...ant > > > - > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Refactoring commonality amongst Script containers in Java SCA
No go for it, that would be great! ...ant On 10/31/06, Jim Marino <[EMAIL PROTECTED]> wrote: So do you mind if I make the changes? Jim On Oct 31, 2006, at 1:02 AM, ant elder wrote: > No, tied up on M2 things, i doubt I'll have time for this till M2 > is done. > > ...ant > > On 10/31/06, Jim Marino <[EMAIL PROTECTED]> wrote: >> >> Any luck in making these changes? >> >> Jim >> >> On Oct 26, 2006, at 8:30 AM, Jim Marino wrote: >> >> >> >> >> >> >> As you don't like the easy SPI extension I've got rid of the easy >> >> extension >> >> dependency of the script container. I've moved the script >> >> container into >> >> trunk as it was going stale and i want to start using and >> >> improving it. It >> >> still uses some of the easy classes which are in a helper package >> >> now, i'll >> >> get rid of them as we clean things up. I saw you've done some core >> >> changes >> >> for the componentType problem, thanks, I'll go look at how to use >> >> that for >> >> this (and the other script containers) and change the code as >> >> appropriate. >> >> You said you'd take on getting the things like the async code into >> >> the spi >> >> to avoid all that duplicate code so would you like to go ahead and >> >> do that >> >> now? (or I can do it if you like). >> > O.K. I committed the changes. There is no need to handle message id >> > correlation as the wiring fabric (specifically >> > TargetInvokerExtension) does it automatically. You should be able >> > to delete AsyncMonitor and the async target invoker. You will also >> > need to change some of the signatures of the builders to pass in a >> > WorkContext and ExectionMonitor (these are autowired to >> > ComponentBuilderExtension). I made some basic changes the the >> > script container to pass tests but you will probably need to do >> > some more (limited) refactoring to get it fully operational. I >> > fixed the Groovy container so you can use that as an example. (BTW, >> > as a side note, container.script is not part of the build by >> default). >> > >> > The other changes to make are to create a script specialization of >> > ComponentType in the loader and use ObjectFactory for creating >> > instances. >> > >> >> Once the componentType and async changes >> >> are done I/we can look at the next things to simplify and once all >> >> that >> >> refactoring is done I'll look at what remains in the helper >> >> package and see >> >> if there are still things I think could be simplified. >> >> >> > If you can make those changes, we can take another pass over the >> > helper classes and see what is left. >> > >> > Jim >> > >> >> ...ant >> > >> > >> > >> - >> > 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] >> >> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Refactoring commonality amongst Script containers in Java SCA
O.K., I committed the refactor to container.script with the follow changes: 1. Fixed the project so it builds again :-) (it is not part of the default build) 2. Removed the need for Async target invokers based on core changes 3. Remove ComponentType hack as that has been fixed in core 4. Changes to better leverage SPI - Removal of all the "helper" classes. I was able to factor these out by using stuff from SPI, class hierarchy simplifications, e.g. ScriptImplementation - Scripts now instantiated in the build phase as opposed to loading - Stronger typing of errors, e.g. MissingSideFileException - Use of ObjectFactory for creating Script instances 5. Fix issue where mutable properties were not thread-safe (i.e. instances were shared across implementation instances). 6. Remove dependency on core impl classes and cleanup some of the unit tests 7. Fix checkstyle warnings and PMD failures 8. Add license file 9 Use a config class for creating a ScriptComponent as that takes a number of constructor parameters There are also some things that could be done as potential improvements: 1. Better test quality. - There are no real tests involving invocations and wires to and from scripts. This could be set up with EasyMock in a pretty straightforward way without the need for SCATestCase - Likewise for properties, we should test accessing properties from within a script. 2. Support for scopes other than module. 3. Some of the class hierarchies seem like they could be simplified, flattened, or removed. For example, ScriptInstance and its implementation could potentially be removed completely and just have the ScriptComponent return the BSF engine (ScriptTargetInvoker would need to be changed for this to carry additional information). Jim On Oct 31, 2006, at 3:05 AM, ant elder wrote: No go for it, that would be great! ...ant On 10/31/06, Jim Marino <[EMAIL PROTECTED]> wrote: So do you mind if I make the changes? Jim On Oct 31, 2006, at 1:02 AM, ant elder wrote: > No, tied up on M2 things, i doubt I'll have time for this till M2 > is done. > > ...ant > > On 10/31/06, Jim Marino <[EMAIL PROTECTED]> wrote: >> >> Any luck in making these changes? >> >> Jim >> >> On Oct 26, 2006, at 8:30 AM, Jim Marino wrote: >> >> >> >> >> >> >> As you don't like the easy SPI extension I've got rid of the easy >> >> extension >> >> dependency of the script container. I've moved the script >> >> container into >> >> trunk as it was going stale and i want to start using and >> >> improving it. It >> >> still uses some of the easy classes which are in a helper package >> >> now, i'll >> >> get rid of them as we clean things up. I saw you've done some core >> >> changes >> >> for the componentType problem, thanks, I'll go look at how to use >> >> that for >> >> this (and the other script containers) and change the code as >> >> appropriate. >> >> You said you'd take on getting the things like the async code into >> >> the spi >> >> to avoid all that duplicate code so would you like to go ahead and >> >> do that >> >> now? (or I can do it if you like). >> > O.K. I committed the changes. There is no need to handle message id >> > correlation as the wiring fabric (specifically >> > TargetInvokerExtension) does it automatically. You should be able >> > to delete AsyncMonitor and the async target invoker. You will also >> > need to change some of the signatures of the builders to pass in a >> > WorkContext and ExectionMonitor (these are autowired to >> > ComponentBuilderExtension). I made some basic changes the the >> > script container to pass tests but you will probably need to do >> > some more (limited) refactoring to get it fully operational. I >> > fixed the Groovy container so you can use that as an example. (BTW, >> > as a side note, container.script is not part of the build by >> default). >> > >> > The other changes to make are to create a script specialization of >> > ComponentType in the loader and use ObjectFactory for creating >> > instances. >> > >> >> Once the componentType and async changes >> >> are done I/we can look at the next things to simplify and once all >> >> that >> >> refactoring is done I'll look at what remains in the helper >> >> package and see >> >> if there are still things I think could be simplified. >> >> >> > If you can make those changes, we can take another pass over the >> > helper classes and see what is left. >> > >> > Jim >> > >> >> ...ant >> > >> > >> > >> - >> > 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] >> >> --
Re: Refactoring commonality amongst Script containers in Java SCA
This hasn't entirely turned out as I was expecting. This container now looks remarkably similar to the other existing ones, I thought we were trying to refactor out the common parts to come up with an easier container SPI? Lets take MissingSideFileException as an example, that could be reused by many container extensions so could be in a container SPI couldn't it? ...ant On 11/4/06, Jim Marino < [EMAIL PROTECTED]> wrote: O.K., I committed the refactor to container.script with the follow changes: 1. Fixed the project so it builds again :-) (it is not part of the default build) 2. Removed the need for Async target invokers based on core changes 3. Remove ComponentType hack as that has been fixed in core 4. Changes to better leverage SPI - Removal of all the "helper" classes. I was able to factor these out by using stuff from SPI, class hierarchy simplifications, e.g. ScriptImplementation - Scripts now instantiated in the build phase as opposed to loading - Stronger typing of errors, e.g. MissingSideFileException - Use of ObjectFactory for creating Script instances 5. Fix issue where mutable properties were not thread-safe (i.e. instances were shared across implementation instances). 6. Remove dependency on core impl classes and cleanup some of the unit tests 7. Fix checkstyle warnings and PMD failures 8. Add license file 9 Use a config class for creating a ScriptComponent as that takes a number of constructor parameters There are also some things that could be done as potential improvements: 1. Better test quality. - There are no real tests involving invocations and wires to and from scripts. This could be set up with EasyMock in a pretty straightforward way without the need for SCATestCase - Likewise for properties, we should test accessing properties from within a script. 2. Support for scopes other than module. 3. Some of the class hierarchies seem like they could be simplified, flattened, or removed. For example, ScriptInstance and its implementation could potentially be removed completely and just have the ScriptComponent return the BSF engine (ScriptTargetInvoker would need to be changed for this to carry additional information). Jim On Oct 31, 2006, at 3:05 AM, ant elder wrote: > No go for it, that would be great! > > ...ant > > On 10/31/06, Jim Marino < [EMAIL PROTECTED]> wrote: >> >> So do you mind if I make the changes? >> >> Jim >> >> On Oct 31, 2006, at 1:02 AM, ant elder wrote: >> >> > No, tied up on M2 things, i doubt I'll have time for this till M2 >> > is done. >> > >> > ...ant >> > >> > On 10/31/06, Jim Marino <[EMAIL PROTECTED]> wrote: >> >> >> >> Any luck in making these changes? >> >> >> >> Jim >> >> >> >> On Oct 26, 2006, at 8:30 AM, Jim Marino wrote: >> >> >> >> >> >> >> >> >> >> >> As you don't like the easy SPI extension I've got rid of the >> easy >> >> >> extension >> >> >> dependency of the script container. I've moved the script >> >> >> container into >> >> >> trunk as it was going stale and i want to start using and >> >> >> improving it. It >> >> >> still uses some of the easy classes which are in a helper >> package >> >> >> now, i'll >> >> >> get rid of them as we clean things up. I saw you've done >> some core >> >> >> changes >> >> >> for the componentType problem, thanks, I'll go look at how >> to use >> >> >> that for >> >> >> this (and the other script containers) and change the code as >> >> >> appropriate. >> >> >> You said you'd take on getting the things like the async >> code into >> >> >> the spi >> >> >> to avoid all that duplicate code so would you like to go >> ahead and >> >> >> do that >> >> >> now? (or I can do it if you like). >> >> > O.K. I committed the changes. There is no need to handle >> message id >> >> > correlation as the wiring fabric (specifically >> >> > TargetInvokerExtension) does it automatically. You should be >> able >> >> > to delete AsyncMonitor and the async target invoker. You will >> also >> >> > need to change some of the signatures of the builders to pass >> in a >> >> > WorkContext and ExectionMonitor (these are autowired to >> >> > ComponentBuilderExtension). I made some basic changes the the >> >> > script container to pass tests but you will probably need to do >> >> > some more (limited) refactoring to get it fully operational. I >> >> > fixed the Groovy container so you can use that as an example. >> (BTW, >> >> > as a side note, container.script is not part of the build by >> >> default). >> >> > >> >> > The other changes to make are to create a script >> specialization of >> >> > ComponentType in the loader and use ObjectFactory for creating >> >> > instances. >> >> > >> >> >> Once the componentType and async changes >> >> >> are done I/we can look at the next things to simplify and >> once all >> >> >> that >> >> >> refactoring is done I'll look at what remains in the helper >> >> >> package and see >> >> >> if there are still things I think could be
Re: Refactoring commonality amongst Script containers in Java SCA
On Nov 8, 2006, at 2:08 PM, ant elder wrote: This hasn't entirely turned out as I was expecting. This container now looks remarkably similar to the other existing ones, I see this as a good sign...to me it means we are arriving at an SPI I thought we were trying to refactor out the common parts to come up with an easier container SPI? Yes and I couldn't find much to factor into the kernel. However, I did factor things out that were redundant with the later. Lets take MissingSideFileException as an example, that could be reused by many container extensions so could be in a container SPI couldn't it? MissingSideFileException could be moved up. However, I would be very cautious about moving implementation classes. There is always a trade- off in SPI design between providing out-of-the-box implementations versus too tightly coupling extensions to the containers they are extending. If there are too many implementation classes in an SPI, it will render the latter inflexible and it will be difficult to evolve in a backward compatible way in the future. For example, we can take a few specifics: 1. ScriptComponentBuilder. Injecting of properties is specific to the implementation type. One thing that we could potentially change is having scope containers passed in. We should think about this. 2. ScriptComponentTypeLoader. How a component type side file is resolved for an implementation type is specific to it. Providing utility classes for trivial operations such as reading streams will just complicate the SPI needlessly. 3. ScriptImplementationLoader. Pretty much the same comments as for ScriptComponentTypeLoader. One thing that could be simplified in the extension (as I mentioned previously) is ScriptInstance could be removed altogether. What do you think? Perhaps I'm just not seeing what could be moved up. Could you elaborate on the specifics? Jim ...ant On 11/4/06, Jim Marino < [EMAIL PROTECTED]> wrote: O.K., I committed the refactor to container.script with the follow changes: 1. Fixed the project so it builds again :-) (it is not part of the default build) 2. Removed the need for Async target invokers based on core changes 3. Remove ComponentType hack as that has been fixed in core 4. Changes to better leverage SPI - Removal of all the "helper" classes. I was able to factor these out by using stuff from SPI, class hierarchy simplifications, e.g. ScriptImplementation - Scripts now instantiated in the build phase as opposed to loading - Stronger typing of errors, e.g. MissingSideFileException - Use of ObjectFactory for creating Script instances 5. Fix issue where mutable properties were not thread-safe (i.e. instances were shared across implementation instances). 6. Remove dependency on core impl classes and cleanup some of the unit tests 7. Fix checkstyle warnings and PMD failures 8. Add license file 9 Use a config class for creating a ScriptComponent as that takes a number of constructor parameters There are also some things that could be done as potential improvements: 1. Better test quality. - There are no real tests involving invocations and wires to and from scripts. This could be set up with EasyMock in a pretty straightforward way without the need for SCATestCase - Likewise for properties, we should test accessing properties from within a script. 2. Support for scopes other than module. 3. Some of the class hierarchies seem like they could be simplified, flattened, or removed. For example, ScriptInstance and its implementation could potentially be removed completely and just have the ScriptComponent return the BSF engine (ScriptTargetInvoker would need to be changed for this to carry additional information). Jim On Oct 31, 2006, at 3:05 AM, ant elder wrote: > No go for it, that would be great! > > ...ant > > On 10/31/06, Jim Marino < [EMAIL PROTECTED]> wrote: >> >> So do you mind if I make the changes? >> >> Jim >> >> On Oct 31, 2006, at 1:02 AM, ant elder wrote: >> >> > No, tied up on M2 things, i doubt I'll have time for this till M2 >> > is done. >> > >> > ...ant >> > >> > On 10/31/06, Jim Marino <[EMAIL PROTECTED]> wrote: >> >> >> >> Any luck in making these changes? >> >> >> >> Jim >> >> >> >> On Oct 26, 2006, at 8:30 AM, Jim Marino wrote: >> >> >> >> >> >> >> >> >> >> >> As you don't like the easy SPI extension I've got rid of the >> easy >> >> >> extension >> >> >> dependency of the script container. I've moved the script >> >> >> container into >> >> >> trunk as it was going stale and i want to start using and >> >> >> improving it. It >> >> >> still uses some of the easy classes which are in a helper >> package >> >> >> now, i'll >> >> >> get rid of them as we clean things up. I saw you've done >> some core >> >> >> changes >> >> >> for the componentType problem, thanks, I'll go look at how >> to use >> >> >> that for >> >> >> this (and the other
Re: Refactoring commonality amongst Script containers in Java SCA
How about adding a scripting utility jar? This would be an additional jar that contained utility classes relevant to scripting extensions that they could all refer too, avoiding duplication but not putting too much implementation in the SPI itself (which I think we all agree should be avoided). -- Jeremy On Nov 8, 2006, at 4:04 PM, Jim Marino wrote: On Nov 8, 2006, at 2:08 PM, ant elder wrote: This hasn't entirely turned out as I was expecting. This container now looks remarkably similar to the other existing ones, I see this as a good sign...to me it means we are arriving at an SPI I thought we were trying to refactor out the common parts to come up with an easier container SPI? Yes and I couldn't find much to factor into the kernel. However, I did factor things out that were redundant with the later. Lets take MissingSideFileException as an example, that could be reused by many container extensions so could be in a container SPI couldn't it? MissingSideFileException could be moved up. However, I would be very cautious about moving implementation classes. There is always a trade-off in SPI design between providing out-of-the-box implementations versus too tightly coupling extensions to the containers they are extending. If there are too many implementation classes in an SPI, it will render the latter inflexible and it will be difficult to evolve in a backward compatible way in the future. For example, we can take a few specifics: 1. ScriptComponentBuilder. Injecting of properties is specific to the implementation type. One thing that we could potentially change is having scope containers passed in. We should think about this. 2. ScriptComponentTypeLoader. How a component type side file is resolved for an implementation type is specific to it. Providing utility classes for trivial operations such as reading streams will just complicate the SPI needlessly. 3. ScriptImplementationLoader. Pretty much the same comments as for ScriptComponentTypeLoader. One thing that could be simplified in the extension (as I mentioned previously) is ScriptInstance could be removed altogether. What do you think? Perhaps I'm just not seeing what could be moved up. Could you elaborate on the specifics? Jim ...ant On 11/4/06, Jim Marino < [EMAIL PROTECTED]> wrote: O.K., I committed the refactor to container.script with the follow changes: 1. Fixed the project so it builds again :-) (it is not part of the default build) 2. Removed the need for Async target invokers based on core changes 3. Remove ComponentType hack as that has been fixed in core 4. Changes to better leverage SPI - Removal of all the "helper" classes. I was able to factor these out by using stuff from SPI, class hierarchy simplifications, e.g. ScriptImplementation - Scripts now instantiated in the build phase as opposed to loading - Stronger typing of errors, e.g. MissingSideFileException - Use of ObjectFactory for creating Script instances 5. Fix issue where mutable properties were not thread-safe (i.e. instances were shared across implementation instances). 6. Remove dependency on core impl classes and cleanup some of the unit tests 7. Fix checkstyle warnings and PMD failures 8. Add license file 9 Use a config class for creating a ScriptComponent as that takes a number of constructor parameters There are also some things that could be done as potential improvements: 1. Better test quality. - There are no real tests involving invocations and wires to and from scripts. This could be set up with EasyMock in a pretty straightforward way without the need for SCATestCase - Likewise for properties, we should test accessing properties from within a script. 2. Support for scopes other than module. 3. Some of the class hierarchies seem like they could be simplified, flattened, or removed. For example, ScriptInstance and its implementation could potentially be removed completely and just have the ScriptComponent return the BSF engine (ScriptTargetInvoker would need to be changed for this to carry additional information). Jim On Oct 31, 2006, at 3:05 AM, ant elder wrote: > No go for it, that would be great! > > ...ant > > On 10/31/06, Jim Marino < [EMAIL PROTECTED]> wrote: >> >> So do you mind if I make the changes? >> >> Jim >> >> On Oct 31, 2006, at 1:02 AM, ant elder wrote: >> >> > No, tied up on M2 things, i doubt I'll have time for this till M2 >> > is done. >> > >> > ...ant >> > >> > On 10/31/06, Jim Marino <[EMAIL PROTECTED]> wrote: >> >> >> >> Any luck in making these changes? >> >> >> >> Jim >> >> >> >> On Oct 26, 2006, at 8:30 AM, Jim Marino wrote: >> >> >> >> >> >> >> >> >> >> >> As you don't like the easy SPI extension I've got rid of the >> easy >> >> >> extension >> >> >> dependency of the script container. I've moved the script >> >> >> container into >> >> >> trunk as it was going stale and i
Re: Refactoring commonality amongst Script containers in Java SCA
Thats an excellent idea. I think there are still parts of this that could be made significantly easier by altering the SPI but I'll be happy to have them in utility jar for now. I'll go do this. ...ant On 11/9/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: How about adding a scripting utility jar? This would be an additional jar that contained utility classes relevant to scripting extensions that they could all refer too, avoiding duplication but not putting too much implementation in the SPI itself (which I think we all agree should be avoided). -- Jeremy On Nov 8, 2006, at 4:04 PM, Jim Marino wrote: > > On Nov 8, 2006, at 2:08 PM, ant elder wrote: > >> This hasn't entirely turned out as I was expecting. This container >> now looks >> remarkably similar to the other existing ones, > I see this as a good sign...to me it means we are arriving at an SPI >> I thought we were trying to >> refactor out the common parts to come up with an easier container >> SPI? > Yes and I couldn't find much to factor into the kernel. However, I > did factor things out that were redundant with the later. >> Lets >> take MissingSideFileException as an example, that could be reused >> by many >> container extensions so could be in a container SPI couldn't it? >> > MissingSideFileException could be moved up. However, I would be > very cautious about moving implementation classes. There is always > a trade-off in SPI design between providing out-of-the-box > implementations versus too tightly coupling extensions to the > containers they are extending. If there are too many implementation > classes in an SPI, it will render the latter inflexible and it will > be difficult to evolve in a backward compatible way in the future. > For example, we can take a few specifics: > > 1. ScriptComponentBuilder. Injecting of properties is specific to > the implementation type. One thing that we could potentially change > is having scope containers passed in. We should think about this. > > 2. ScriptComponentTypeLoader. How a component type side file is > resolved for an implementation type is specific to it. Providing > utility classes for trivial operations such as reading streams will > just complicate the SPI needlessly. > > 3. ScriptImplementationLoader. Pretty much the same comments as for > ScriptComponentTypeLoader. > > One thing that could be simplified in the extension (as I mentioned > previously) is ScriptInstance could be removed altogether. What do > you think? > > Perhaps I'm just not seeing what could be moved up. Could you > elaborate on the specifics? > > Jim > > > >> ...ant >> >> On 11/4/06, Jim Marino < [EMAIL PROTECTED]> wrote: >>> >>> O.K., I committed the refactor to container.script with the follow >>> changes: >>> >>> 1. Fixed the project so it builds again :-) (it is not part of the >>> default build) >>> >>> 2. Removed the need for Async target invokers based on core changes >>> >>> 3. Remove ComponentType hack as that has been fixed in core >>> >>> 4. Changes to better leverage SPI >>> - Removal of all the "helper" classes. I was able to >>> factor these >>> out by using stuff from SPI, class hierarchy simplifications, e.g. >>> ScriptImplementation >>> - Scripts now instantiated in the build phase as opposed to >>> loading >>> - Stronger typing of errors, e.g. MissingSideFileException >>> - Use of ObjectFactory for creating Script instances >>> >>> 5. Fix issue where mutable properties were not thread-safe (i.e. >>> instances were shared across implementation instances). >>> >>> 6. Remove dependency on core impl classes and cleanup some of the >>> unit tests >>> >>> 7. Fix checkstyle warnings and PMD failures >>> >>> 8. Add license file >>> >>> 9 Use a config class for creating a ScriptComponent as that takes a >>> number of constructor parameters >>> >>> >>> There are also some things that could be done as potential >>> improvements: >>> >>> 1. Better test quality. >>> - There are no real tests involving invocations and wires >>> to and >>> from scripts. This could be set up with EasyMock in a pretty >>> straightforward way without the need for SCATestCase >>> - Likewise for properties, we should test accessing >>> properties >>> from within a script. >>> >>> 2. Support for scopes other than module. >>> >>> 3. Some of the class hierarchies seem like they could be simplified, >>> flattened, or removed. For example, ScriptInstance and its >>> implementation could potentially be removed completely and just have >>> the ScriptComponent return the BSF engine (ScriptTargetInvoker would >>> need to be changed for this to carry additional information). >>> >>> >>> Jim >>> >>> On Oct 31, 2006, at 3:05 AM, ant elder wrote: >>> >>> > No go for it, that would be great! >>> > >>> > ...ant >>> > >>> > On 10/31/06, Jim Marino < [EMAIL PROTECTED]> wrote: >>> >> >>> >> So do you mind if I make the changes? >>> >> >>> >> Jim >>> >> >>> >> On Oct 31, 2006, at 1:02 AM, ant elde
