Is it possible to create new commands that are callable via "eval" in a test case?

Question

question

tlawall asked Jan 16, '10 tlawall posted Jan 16, '10

Is it possible to create new commands that are callable via "eval" in a test case?

Is it possible to create a new command that is callable via "eval" in a test case?

What I would like to do is collect data during my test case, then turn around and feed it through some code that I have written in java that formats it in a specific way whcih is then returned to the test case. I have read about creating a process/application session type and tying in code that way, but I was really curious to know if I could "extend the command set" of the built in tcl command set. Is this possible?

An example of use would be doing some "lappend"s to a list in the test case, then feeding the list to my function that then runs the java code underneath to format the data. This command then returns the formatted data to the test case.

Thanks!

Todd

iTest sdk

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Answer 1 · 2010-01-16T01:54:14Z

PaulD answered Jan 16, '10 PaulD posted Jan 16, '10

The extension point to define new commands is not currently exposed at a supported interface. However, you can accomplish a similar thing by using Tcl itself. You can write your extension in Tcl, and then you can just use scriptEval instead of eval to invoke that code.

Perhaps we will think about opening up this interface for defining and implementing new interpreter commands.

6

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

KumarS commented · Jan 16, 2010 at 04:24 PM

Since your command is trying to use both Java and Tcl to do its job, you may also consider developing a tool. The tool SDK will let you define a session with a number of "actions" which you can define. (In this case, lappend will be an action in your tool instead of a command - but you can also design it so that your tool action is "eval" and the command body can contain any command which you will parse). Each action will be implemented in Java - but you can have a mixture of calling tcl shell and processing the results in java before returning the processed data to iTest.

There is SDK tutorial available to show how to create a simple example. This will require knowledge of Java programming and Eclipse plugin development.

Paul's suggestion of simply doing it all in Tcl is a much simpler solution - but you will have to do everything in tcl.

0 ·

tlawall commented · Jan 18, 2010 at 06:47 PM

Paul,

Thanks for the response. Yes, implementing new interpreter commands would be quite nice, mostly because I'd like to use some of the Java libraries I have without having to shell out to an SSH session, or CMD session. It's mainly a performance question for us, as we have a function that is currently implemented in perl, that is called via an SSH session for every procedure that we have. Over a nightly run of a test suite, I'm afraid this will add up to the point that it causes pain. The application interface will have to suffice, because that still allows me to tie code I'm will use into iTest (closer than external tools would be). However, for my user's sake, a new tcl command that is built into the interpreter would be better.

Here's a reason why we're attempting to do this: it gets back to the question I believe you answered the other day, about building some XML off of XPath data. For the sake of returning a standard interface from our procedures in our library that we're creating, we chose to return XML from each and every function. This means that we must build an XML response. We have a tool that currently takes XPaths and values and forms an XML doc (even if it's one value) that gets returned from every library procedure. However, this tool is the perl tool I mentioned above, and it requires shelling out to use it. While this isn't optimal, at the moment it's the only way we've found to do this kind of creation of XML from within iTest. I'd love to wrap up the functionality into some module that we include in our iTest deployment that can do the same thing, but without any of the overhead that it will currently take for this method. It would be nice from my user's perspective to simply build up a list of XPaths from within their procedures, then hand it to a tcl interpreter command that I've built, and have it return the XML response that can then be returned to the caller.

Does this make sense?

0 ·

PaulD tlawall commented · Jan 18, 2010 at 11:54 PM

I'm not sure I would take that approach, but I do understand what you are doing. Our goal is definitely to facilitate a variety of usage patterns. And we would like to open up a lot more of the internals to allow developers like you to be able to extend the platform further by writing Java code. At this point, it is mainly a question of priorities over what to work on for opening things up. Opening up the interface for defining new interpreter commands should be quite straightforward -- with the exception of having to worry about naming collisions among multiple implementers of these commands. So we might recommend some kind of "best practices" around command naming conventions to avoid such collisions.

0 ·

BillS tlawall commented · Feb 15, 2010 at 09:42 PM

Since iTest's internal Tcl interp is actually Jacl (http://tcljava.sourceforge.net/docs/website/index.html), you should be able to use the Jacl-supplied mechanisms to load and execute your code. You' d have to deal with classpaths, etc, but that's a lot easier than core extensions.

So you'd:

- call "package require java"

- Create a Tcl proc which contains your interop with Java code via Jacl mechanisms

- Call that Tcl proc in the eval

Of course if you have it set up so you can pass in data to an obj constructor and it does what you want... you could technically do something like:

package require java

set jobj [java::new MyClass "My data goes here"]

as shown in the java::new String example on the link above.

0 ·

PaulD BillS commented · Feb 15, 2010 at 10:45 PM

Be careful. Eclipse (and therefore iTest) uses an OSGi kernel, and therefore there are some funny things about Java class loaders going on. (Each plugin has its own Java class loader.) I haven't really thought a lot about this, but you may find it difficult to get the Jacl code to find your Java code.

0 ·

BillS PaulD commented · Feb 15, 2010 at 11:20 PM

Yup, there are all sortsof cautions/pitfalls/etc. Putting the code and its dependencies into its own plugin would be one way of improving chances of success, but it's more of a "If I don;t have any other options, what the heck" approach than a robust mechanism.

Personally I'd put the absolute bare minimum code into the local Java class, and have it call a remote RESTful API...

0 ·

question