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]
