Bug 55203 - TestBeanGUI - wrong language settings found
TestBeanGUI - wrong language settings found
Status: RESOLVED FIXED
Product: JMeter
Classification: Unclassified
Component: Main
2.9
PC Windows XP
: P2 normal (vote)
: ---
Assigned To: JMeter issues mailing list
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2013-07-06 13:55 UTC by Sebb
Modified: 2013-07-30 19:43 UTC (History)
1 user (show)



Attachments
Test case (2.53 KB, text/plain)
2013-07-07 11:19 UTC, Sebb
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sebb 2013-07-06 13:55:49 UTC
The BSF and JSR223 test elements share some common classes and code.

It looks like the Bean Code is getting confused, because the list of languages for BSF and JSR223 always displays the same.

There are several common entries, but there are some languages that are only supported by one of the scripting interfaces. For example:

Both
beanshell
java

BSF only
beanbasic
bml
xslt

JSR223 only
ecmascript
rhino

I think this is related to the fact that the same field name is used for both sets of classes. It looks like only one of the "language" field definitions is being found by JMeter; sometimes it will be the wrong one.
Comment 1 Marko 2013-07-07 06:10:49 UTC
This issue started in 2.9. In 2.8 it is all good.
Comment 2 Sebb 2013-07-07 11:19:09 UTC
Broken in 2.8 for me.

I first tried adding BSF and JSR223 samplers to Workbench - looked OK.
I then moved them under Thread Group and saved as JMX (to follow).
On reload, both the drop-downs showed the same list.

I think the problem is that the same PropertyDescriptor instances are created for what should be different beans. I don't know why that is yet, probably because the beans share inherited information. Maybe the Introspector parameters are wrong.
Comment 3 Sebb 2013-07-07 11:19:59 UTC
Created attachment 30561 [details]
Test case
Comment 4 Philippe Mouawad 2013-07-07 19:38:00 UTC
I think regression came from 54110.

sebb regarding your test case, I just put them as children of Workbench and I see they have the same language while they should not
Comment 5 Philippe Mouawad 2013-07-07 20:05:53 UTC
Date: Sun Jul  7 20:04:34 2013
New Revision: 1500526

URL: http://svn.apache.org/r1500526
Log:
Bug 55203 - TestBeanGUI - wrong language settings found
Bugzilla Id: 55203

Modified:
    jmeter/trunk/src/protocol/java/org/apache/jmeter/protocol/java/sampler/JSR223SamplerBeanInfo.java
Comment 6 Philippe Mouawad 2013-07-07 20:36:48 UTC
Debugging I see the 2 classes share the same PropertyDescriptor instance.
Comment 7 Sebb 2013-07-07 22:17:23 UTC
Yes, they share the same rootBeanInfo class, i.e. java.beans.GenericBeanInfo, which I think is the problem here. Although they are obviously different instances, the class is what seems to be used for distinguishing cached elements.
Comment 8 Sebb 2013-07-07 22:17:56 UTC
(In reply to Philippe Mouawad from comment #5)
> Date: Sun Jul  7 20:04:34 2013
> New Revision: 1500526
> 
> URL: http://svn.apache.org/r1500526
> Log:
> Bug 55203 - TestBeanGUI - wrong language settings found
> Bugzilla Id: 55203
> 
> Modified:
>    
> jmeter/trunk/src/protocol/java/org/apache/jmeter/protocol/java/sampler/
> JSR223SamplerBeanInfo.java

Good catch, but unfortunately not the solution.
Comment 9 Sebb 2013-07-07 22:51:44 UTC
I tried removing the shared setup from the ScriptingBeanInfoSupport class and copied it down to the BSF and JSR223 classes, and that does not make any difference either
Comment 10 Sebb 2013-07-07 23:27:04 UTC
(In reply to Philippe Mouawad from comment #4)
> I think regression came from 54110.

Bug 54110 moved the common fields and setters/getters to a shared super-class.

I just tried moving them back, and it does not fix the issue.
Comment 11 Sebb 2013-07-08 00:46:05 UTC
(In reply to Sebb from comment #10)
> (In reply to Philippe Mouawad from comment #4)
> > I think regression came from 54110.
> 
> Bug 54110 moved the common fields and setters/getters to a shared
> super-class.
> 
> I just tried moving them back, and it does not fix the issue.

Oops, sorry - I thought the lists looked the same, but I'd forgotten I'd converted JSR223 to all lower case and I was looking for an uppercase entry.
Should have checked more carefully.

The problem does seem to be the shared class with different requirements for the TAG field.

However, it does not seem to be a problem for the other shared fields where the attributes may vary - e.g. scripting.displayName which shows the different script variables that are available.
Comment 12 Sebb 2013-07-08 00:50:53 UTC
Hopefully this fixes the issue:

URL: http://svn.apache.org/r1500556
Log:
TestBeanGUI - wrong language settings found
Bugzilla Id: 55203

Modified:
    jmeter/trunk/src/core/org/apache/jmeter/util/BSFTestElement.java
    jmeter/trunk/src/core/org/apache/jmeter/util/JSR223TestElement.java
    jmeter/trunk/src/core/org/apache/jmeter/util/ScriptingTestElement.java
    jmeter/trunk/xdocs/changes.xml

Leaving open for now in case there are other shared parameters that need moving
Comment 13 Philippe Mouawad 2013-07-08 06:56:51 UTC
(In reply to Sebb from comment #7)
> Yes, they share the same rootBeanInfo class, i.e.
> java.beans.GenericBeanInfo, which I think is the problem here. Although they
> are obviously different instances, the class is what seems to be used for
> distinguishing cached elements.

They really share the same instance.
Issue also affects short description for example.
Comment 14 Philippe Mouawad 2013-07-08 07:06:55 UTC
Issue no more apparent with moving scriptLanguage to 2 subclasses
Comment 15 Sebb 2013-07-08 08:10:28 UTC
I think it must have been a combination of the two issues.

JMeter 2.7 has the problem, and was before the properties were moved to the shared super-class. However the JSR223SamplerBeanInfo class extended the wrong base class.

==

There are still properties that are shared between GUI classes - e.g. all the JSR223 classes share the same definition of the "script" property.

The TAGS field is an attribute of the "script" PropertyDescriptor which varies between sub-classes whereas the other attributes are identical to all sub-classes.

I think that is probably why they work OK; the PropertyDescriptor is used to look-up the names and types of the properties which don't vary. It was only the TAGS attribute that varied.