[ grinder-Feature Requests-1949447 ] write test scripts in Java

[SourceForge.net]

Feature Requests item #1949447, was opened at 2008-04-23 08:24
Message generated for change (Comment added) made by philipa
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=368598&aid=1949447&group_id=18598

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core engine
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Juergen Weber (weberjn)
Assigned to: Philip Aston (philipa)
Summary: write test scripts in Java

Initial Comment:
It should be supported to run tests in Java instead of Jython. There should be an optional property

grinder.agent=com.mycompany.Mytest
corresponding to
grinder.script=grinder.py

* For Java programmers it is easier to write tests in Java than in any other language.

* Java programmers have lots more know-how in Java than in any other langage.

* Turn-around-time in Java is as fast as in Jython: just press CTRL-S in Eclipse.

* Java-syntax-checking is enabled by default in Eclipse.

----------------------------------------------------------------------

>Comment By: Philip Aston (philipa)
Date: 2008-06-05 13:21

Message:
Logged In: YES
user_id=2117
Originator: NO

Jython doesn't use byte code modification. Call dispatch from Jython-land
is always passed through an intermediate Java wrapper.

Its a significant piece of work to do this type of instrumentation. I
personally don't have the time to implement it. I suspect that the improved
support for dynamic languages in future versions of Java (Java 7?) may make
this easier. So I'm afraid I'm not doing anything with this FR for now. On
the other hand, if someone wants to have a crack at it I'll be happy to
support the effort.

- Phil

----------------------------------------------------------------------

Comment By: Keith Kowalczykowski (keithpk)
Date: 2008-05-26 18:32

Message:
Logged In: YES
user_id=1508422
Originator: NO

Hi Philip, sorry about the name mix up there. ;) Yes, you are right that
AspectJ (or any other byte-code injection) will not support the Grinder
contract of instrumenting individual objects directly out of the box. This
is due to the Java contract that all methods are defined on the underlying
Class object, and therefore, you can only instrument the class (and thus
all instances) or nothing at all. Therefore, it is un-likely that you will
ever find a Java-based solution does exactly what you want it to do.
Therefore, this is why I proposed the work-around of pre-instrumenting
everything, and only enabling instrumentation on a per-instance basis.
Although it sounds heavy, I think you will be surprised at how performant
it actually is. For example, YourKit uses the exact same approach to get
their profiling results, with little additional overhead. I suggest you
write a few sample tests, as I think the performance over-head will be much
less than you think.

 -Keith

As a side note, I question how Jython implements the per-instance
instrumentation behavior to begin with. I'm not a Jython expert, however, I
don't see how they can do this within constraints of the Java language
itself. I would guess they use some type of byte-code injection themselves.
I would suggest you inquire with them to see how they do it, as I wouldn't
be surprised to hear they use byte-code injection.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-05-16 10:22

Message:
Logged In: NO

This feature would be gratly appreciated. After this i think Java
prgrammers can think of using Grinder as something in their backyard.

----------------------------------------------------------------------

Comment By: Philip Aston (philipa)
Date: 2008-05-16 07:49

Message:
Logged In: YES
user_id=2117
Originator: NO

Sheesh, 4 duplicate posts - some my think I like the sound of my own
voice.  I promise its some weird interaction between my browser and SF that
causes these multiple submissions. This is me trying again with a separate
FF profile.

----------------------------------------------------------------------

Comment By: Philip Aston (philipa)
Date: 2008-05-16 07:45

Message:
Logged In: YES
user_id=2117
Originator: NO

Thanks Keith (and its "Philip" BTW, so I hope you're not "Keithpk" :-)),
but I still think that AspectJ doesn't allow us to support the existing
grinder contract for instrumented code.

The work naturally, wrap() has to take an existing object and instrument
it there and then. Since AspectJ does its weaving through byte code
modification at class loading time, it can't do this. The class has already
been loaded.

In your second paragraph, you suggest a workaround of pre-instrumenting
the classes and then using a per-class flag to control the instrumentation.
I'm not an AspectJ expert, but I don't think this would be practical. You
would have to instrument *everything*, and since The Grinder can wrap
classes, methods, functions, and objects there may be more instrumentation
than real code. Even if the check is lightweight, it would still be made
many thousands of times for every action.

----------------------------------------------------------------------

Comment By: Philip Aston (philipa)
Date: 2008-05-16 07:45

Message:
Logged In: YES
user_id=2117
Originator: NO

Thanks Keith (and its "Philip" BTW, so I hope you're not "Keithpk" :-)),
but I still think that AspectJ doesn't allow us to support the existing
grinder contract for instrumented code.

The work naturally, wrap() has to take an existing object and instrument
it there and then. Since AspectJ does its weaving through byte code
modification at class loading time, it can't do this. The class has already
been loaded.

In your second paragraph, you suggest a workaround of pre-instrumenting
the classes and then using a per-class flag to control the instrumentation.
I'm not an AspectJ expert, but I don't think this would be practical. You
would have to instrument *everything*, and since The Grinder can wrap
classes, methods, functions, and objects there may be more instrumentation
than real code. Even if the check is lightweight, it would still be made
many thousands of times for every action.

----------------------------------------------------------------------

Comment By: Philip Aston (philipa)
Date: 2008-05-16 07:45

Message:
Logged In: YES
user_id=2117
Originator: NO

Thanks Keith (and its "Philip" BTW, so I hope you're not "Keithpk" :-)),
but I still think that AspectJ doesn't allow us to support the existing
grinder contract for instrumented code.

The work naturally, wrap() has to take an existing object and instrument
it there and then. Since AspectJ does its weaving through byte code
modification at class loading time, it can't do this. The class has already
been loaded.

In your second paragraph, you suggest a workaround of pre-instrumenting
the classes and then using a per-class flag to control the instrumentation.
I'm not an AspectJ expert, but I don't think this would be practical. You
would have to instrument *everything*, and since The Grinder can wrap
classes, methods, functions, and objects there may be more instrumentation
than real code. Even if the check is lightweight, it would still be made
many thousands of times for every action.

----------------------------------------------------------------------

Comment By: Philip Aston (philipa)
Date: 2008-05-16 07:45

Message:
Logged In: YES
user_id=2117
Originator: NO

Thanks Keith (and its "Philip" BTW, so I hope you're not "Keithpk" :-)),
but I still think that AspectJ doesn't allow us to support the existing
grinder contract for instrumented code.

The work naturally, wrap() has to take an existing object and instrument
it there and then. Since AspectJ does its weaving through byte code
modification at class loading time, it can't do this. The class has already
been loaded.

In your second paragraph, you suggest a workaround of pre-instrumenting
the classes and then using a per-class flag to control the instrumentation.
I'm not an AspectJ expert, but I don't think this would be practical. You
would have to instrument *everything*, and since The Grinder can wrap
classes, methods, functions, and objects there may be more instrumentation
than real code. Even if the check is lightweight, it would still be made
many thousands of times for every action.

----------------------------------------------------------------------

Comment By: Keith Kowalczykowski (keithpk)
Date: 2008-05-16 00:34

Message:
Logged In: YES
user_id=1508422
Originator: NO

Philipa,

I'm not very clear about the internal workings of Grinder, so maybe I'm
missing something, however, what you want to do seems completely possible
with AspectJ. The way I interpret it is that you essentially want to be
able to "wrap" any arbitrary object so you can do timing, etc. This is
essentially Test.wrap(). With AspectJ, you can indicate that some (or all)
of a given classes methods should be instrumented. A good example of doing
this is in AspectJ's own documentation
(http://www.eclipse.org/aspectj/doc/released/progguide/starting-development.html#tracing).


I believe your stumbling block, however, is that you only want to do
performance analysis only on objects that are passed to wrap(). Although
AspectJ does not let you weave particular instances, you can easily fix
this. Essentially for all classes that you weave, you would have AspectJ
add a enableInstrumentation(boolean) method.(See
http://www.eclipse.org/aspectj/doc/released/progguide/examples-production.html#a-bean-aspect).
Then when wrap() is called, you would essentially just set this flag to
true. In this way, you would instrument everything, but only enable
instrumentation on objects which have been passed to wrap().

Hopefully this makes sense, and solves you problems. As a Java developer,
I would love to be able to use Java, instead of having to learn Jython. Let
me know if you have any additional questions.

----------------------------------------------------------------------

Comment By: Philip Aston (philipa)
Date: 2008-05-01 16:40

Message:
Logged In: YES
user_id=2117
Originator: NO

AspectJ doesn't help us translate the existing interface to Java. As with
other Java AOP mechanisms, you need to declare the aspects before you
create an instance. You can't pass it an existing instance and say
"instrument this". (If you can show me differently, I'd love to know).

The low tech solutions are the only way I can see. Out of three you
suggest, I prefer the one based on Runnable. I'm inclined to defer doing
anything on this until Java 7 has better defined closures.

Of course, if you or anyone else would like to  prototype some solutions,
I'd be interested in what you discover.

----------------------------------------------------------------------

Comment By: Juergen Weber (weberjn)
Date: 2008-04-24 13:59

Message:
Logged In: YES
user_id=918796
Originator: YES

Maybe one could instrument the test via AspectJ? I believe they have an
Eclipse integration.

But what about a low-tech solution? I'd have no problem with

grinder.startMethod("getcustomer");
getCustomer(...);
grinder.endMethod("getcustomer");

or hide grinder behind a log appender:

Logger logger = Logger.getLogger("grinder");
grinder.log("getcustomer");
getCustomer(...);
grinder.log("getcustomer");

and hope the log calls match.



or

grinder.run(new Runnable() ....  getCustomer(...); ....)


This would mean an extra class for Grinder tests, but usually you have
extra classes for unittests, why not another one for Grinder.


----------------------------------------------------------------------

Comment By: Philip Aston (philipa)
Date: 2008-04-23 11:47

Message:
Logged In: YES
user_id=2117
Originator: NO

I'd like to do this, but I've been unable to find a reasonable way to
instrument Java objects.

(Its done in Jython by fiddling with the internal dispatch). The "obvious"
answers (e.g. cglib) don't let you wrap around an existing instance that
doesn't have a default constructor. How else to create a new proxy that
supports all the methods + interfaces - it clearly needs to extend the
target? What if we don't care about implementing the interfaces - just
create a proxy that supports the same methods as its delegate? CGLib
doesn't appear to support this.

Suggestions welcome.

----------------------------------------------------------------------

Comment By: Philip Aston (philipa)
Date: 2008-04-23 11:47

Message:
Logged In: YES
user_id=2117
Originator: NO

I'd like to do this, but I've been unable to find a reasonable way to
instrument Java objects.

(Its done in Jython by fiddling with the internal dispatch). The "obvious"
answers (e.g. cglib) don't let you wrap around an existing instance that
doesn't have a default constructor. How else to create a new proxy that
supports all the methods + interfaces - it clearly needs to extend the
target? What if we don't care about implementing the interfaces - just
create a proxy that supports the same methods as its delegate? CGLib
doesn't appear to support this.

Suggestions welcome.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=368598&aid=1949447&group_id=18598

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Grinder-development mailing list
Grinder-development@...
https://lists.sourceforge.net/lists/listinfo/grinder-development