Variables are not resolved from arguments to Java libraries

[GoogleCodeExporter]

We import the attached html file as a resource in a suite. The class 
    com.ourcompany.robot.SQLLibrary has a constructor accepting the driver name 
and the connection string to construct the library, there are methods to 
connect/disconnect and to return query results etc.. With RF 2.1.3 this worked 
well, with RF 2.5 this fails to run producing this SQLException:

java.sql.SQLException: The syntax of the connection URL 
'jdbc:jtds:sqlserver://${DB_HOST}:${DB_PORT}/Manage' is invalid.

The connection doesn't happen on library construction, but when the connect 
method is called in one of the test case in the suite importing this resource 
file. This means the suite has initialised the library but not using the 
resolved variable strings, else it would not fail.

Environment: 
- XP 64bit
- JDK 1.6.0_16 on  
- Jython 2.5.1 
- RF 2.5

Original issue reported on code.google.com by kai.hack...@gmail.com on 9 Jul 2010 at 12:04

Attachments:

• environment.html

[GoogleCodeExporter]

Your variable table seems to miss the header. Are you sure exactly this file 
passes with RF 2.1.3? Do you got any errors when you run tests?

Original comment by pekka.klarck on 9 Jul 2010 at 8:41

[GoogleCodeExporter]

um... maybe I have deleted a row too much. The file contained some 
company-private settings...

Original comment by kai.hack...@gmail.com on 9 Jul 2010 at 9:09

[GoogleCodeExporter]

I have attached a cleaned up environment html and a cut down version of our SQL 
library class. 

Create a test suite that loads the environment.html as resource, then create a 
test case where you call the connect method of the SQLLibrary class. Requires a 
JDBC driver in classpath and access to a database this driver is suitable for ;)

Cheers,
Kai

Original comment by kai.hack...@gmail.com on 11 Jul 2010 at 10:55

Attachments:

• environment.html
• SQLLibrary.java

[GoogleCodeExporter]

The provided example doesn't include test case file to run, and I don't have 
JDBC drivers on this machine, so I cannot test it. I tried creating similar 
example on my machine but that works fine. This example is attached, could you 
Kai try it on your environment? If it works fine, could you try creating an 
example that has no external dependencies I could easily run on my machine?

Original comment by pekka.klarck on 12 Jul 2010 at 10:11

Attachments:

• args.py
• res.txt
• tc.txt

[GoogleCodeExporter]

Your example works here, too. I'll try now write now a proof of concept with a 
Java library without side dependencies..

Original comment by kai.hack...@gmail.com on 13 Jul 2010 at 12:47

[GoogleCodeExporter]

Attached a slightly modified example of your files. 
- Compile that java file using the command "javac ExampleLib.java" in the same 
folder where the other files sit.
- Run "jybot ." in that same folder
- check the produced log.html file. 

Original comment by kai.hack...@gmail.com on 13 Jul 2010 at 1:01

Attachments:

• res.txt
• tc.txt
• ExampleLib.java

[GoogleCodeExporter]

I was able to reproduce the problem using the provided ExampleLib.java. Thanks 
for providing the example!

I tested that the WITH NAME syntax doesn't cause the problem. By guess is that 
this regression is somehow related to the new named argument syntax. Needs to 
be investigated further and fixed in RF 2.5.1.

Original comment by pekka.klarck on 13 Jul 2010 at 8:36

• Changed state: Accepted
• Added labels: Priority-High, Target-2.5.1
• Removed labels: Priority-Medium

[GoogleCodeExporter]

The problem only appeared with Java libraries and the fix was simple as seen in 
r3811.

This regression was caused by heavy refactorings in RF 2.5 and by the fact that 
we didn't have any test for it. I noticed that the tests for library imports 
with arguments were pretty bad in general, and the biggest part of fixing this 
issue was enhancing them in r3808 and r3810.

Original comment by pekka.klarck on 13 Jul 2010 at 2:07

• Changed title: Variables are not resolved from arguments to Java libraries
• Changed state: Done

[GoogleCodeExporter]

My fix broke importing Java libs in some cases. That was fixed in r3814 so the 
current trunk should work fine. Kai, it would be great if you had a change to 
test this.

Original comment by pekka.klarck on 15 Jul 2010 at 9:39

[GoogleCodeExporter]

Our test suites are running fine now. I think this bug is solved.

Original comment by kai.hack...@gmail.com on 16 Jul 2010 at 12:06