On 8/8/06, Jimmy, Jing Lv wrote:
Stepan Mishura wrote:
> On 8/7/06, *Jimmy, Jing Lv* wrote:
>
>
> Sounds pretty good :)
> "exec" do helps, it can check simple situations.
> What I'm concern is that if the return code is not enough for some
> situations, e.g, what exception
Stepan Mishura wrote:
On 8/7/06, *Jimmy, Jing Lv* wrote:
Sounds pretty good :)
"exec" do helps, it can check simple situations.
What I'm concern is that if the return code is not enough for some
situations, e.g, what exception is thrown exactly, or what cause VM exit
ab
On 8/7/06, Jimmy, Jing Lv wrote:
Sounds pretty good :)"exec" do helps, it can check simple situations.What I'm concern is that if the return code is not enough for some
situations, e.g, what exception is thrown exactly, or what cause VM exitabnormally. IMHO, it is still necessary for us.
Hi Jimm
On 8/7/06, Jimmy, Jing Lv <[EMAIL PROTECTED]> wrote:
Leo Li wrote:
> Hi, all:
> I have some idea to test instrument.
> For example, if we would like to test
> Instrumentation.addTransformerwill throw NullPointerException if the
> argument is null,
> we can first write a TestInstrumen
On 8/7/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
And you forgot to mention cases when tested VM hangs :)
Still, almost any of those situations may be tested automatically,
just fork a tested JVM and setup timeout watchdog. You may examine
1) return value (via j.lProcess.exitValue());
2) ou
Jimmy, Jing Lv wrote:
> Geir Magnusson Jr wrote:
>>
>> Jimmy, Jing Lv wrote:
>>> Richard Liang wrote:
Jimmy, Jing Lv wrote:
> Hi,
>
> As it is hard to write unit test for package instrument, I now
> have an idea: write down some documents for details of non-unit test
2006/8/7, Jimmy, Jing Lv <[EMAIL PROTECTED]>:
Leo Li wrote:
> Hi, all:
> I have some idea to test instrument.
> For example, if we would like to test
> Instrumentation.addTransformerwill throw NullPointerException if the
> argument is null,
> we can first write a TestInstrument with p
Leo Li wrote:
Hi, all:
I have some idea to test instrument.
For example, if we would like to test
Instrumentation.addTransformerwill throw NullPointerException if the
argument is null,
we can first write a TestInstrument with premain function.
import java.lang.instrument.Instrumentat
Paulex Yang wrote:
Jimmy, Jing Lv wrote:
Hi,
As it is hard to write unit test for package instrument, I now
have an idea: write down some documents for details of non-unit test
cases for instrument. The detail of such test cases contain:
1. The test run on which platform, including speci
Hi, all:
I have some idea to test instrument.
For example, if we would like to test
Instrumentation.addTransformerwill throw NullPointerException if the
argument is null,
we can first write a TestInstrument with premain function.
import java.lang.instrument.Instrumentation;
public cla
Geir Magnusson Jr wrote:
Jimmy, Jing Lv wrote:
Richard Liang wrote:
Jimmy, Jing Lv wrote:
Hi,
As it is hard to write unit test for package instrument, I now
have an idea: write down some documents for details of non-unit test
cases for instrument. The detail of such test cases contain:
Jimmy, Jing Lv wrote:
Hi,
As it is hard to write unit test for package instrument, I now
have an idea: write down some documents for details of non-unit test
cases for instrument. The detail of such test cases contain:
1. The test run on which platform, including special environment;
2. T
Richard Liang wrote:
Jimmy, Jing Lv wrote:
Richard Liang wrote:
Jimmy, Jing Lv wrote:
Hi,
As it is hard to write unit test for package instrument, I now
have an idea: write down some documents for details of non-unit test
cases for instrument. The detail of such test cases contain:
Jimmy, Jing Lv wrote:
> Richard Liang wrote:
>>
>>
>> Jimmy, Jing Lv wrote:
>>> Hi,
>>>
>>> As it is hard to write unit test for package instrument, I now
>>> have an idea: write down some documents for details of non-unit test
>>> cases for instrument. The detail of such test cases contain:
Jimmy, Jing Lv wrote:
Richard Liang wrote:
Jimmy, Jing Lv wrote:
Hi,
As it is hard to write unit test for package instrument, I now
have an idea: write down some documents for details of non-unit test
cases for instrument. The detail of such test cases contain:
Do you mean it's hard
Richard Liang wrote:
Jimmy, Jing Lv wrote:
Hi,
As it is hard to write unit test for package instrument, I now
have an idea: write down some documents for details of non-unit test
cases for instrument. The detail of such test cases contain:
Do you mean it's hard to *write* unit test or i
2006/8/3, Paulex Yang <[EMAIL PROTECTED]>:
Gregory Shimansky wrote:
> I don't think there is any conversion required. I believe -javaagent is
a VM
> option and should be handled internally by the invocation API in case
there
> is a 3rd party launcher/plugin which tries to use VM's invocation API
Jimmy, Jing Lv wrote:
Hi,
As it is hard to write unit test for package instrument, I now
have an idea: write down some documents for details of non-unit test
cases for instrument. The detail of such test cases contain:
Do you mean it's hard to *write* unit test or it's hard to integrate
Paulex Yang wrote:
Gregory Shimansky wrote:
On Wednesday 02 August 2006 17:30 Paulex Yang wrote:
Alexey Varlamov wrote:
[SNIP]
For native codes, instrument need a new directory in
modules/luni/src/main/native named "instrument", in my plan, there
should be two native code, on
Hi,
As it is hard to write unit test for package instrument, I now have
an idea: write down some documents for details of non-unit test cases
for instrument. The detail of such test cases contain:
1. The test run on which platform, including special environment;
2. The test description;
3.
Gregory Shimansky wrote:
On Wednesday 02 August 2006 17:30 Paulex Yang wrote:
Alexey Varlamov wrote:
[SNIP]
For native codes, instrument need a new directory in
modules/luni/src/main/native named "instrument", in my plan, there
should be two native code, one for instrument
On Wednesday 02 August 2006 17:30 Paulex Yang wrote:
> Alexey Varlamov wrote:
> > [SNIP]
> >
> >> For native codes, instrument need a new directory in
> >> modules/luni/src/main/native named "instrument", in my plan, there
> >> should be two native code, one for instrument native implementation
Alexey Varlamov wrote:
[SNIP]
For native codes, instrument need a new directory in
modules/luni/src/main/native named "instrument", in my plan, there
should be two native code, one for instrument native implementation, and
another for laugher (for parameter "-javaagent"). Instrument shall be
[SNIP]
For native codes, instrument need a new directory in
modules/luni/src/main/native named "instrument", in my plan, there
should be two native code, one for instrument native implementation, and
another for laugher (for parameter "-javaagent"). Instrument shall be
compiled into a .DLL(.s
Jimmy, Jing Lv wrote:
Stepan Mishura wrote:
On 8/2/06, Jimmy, Jing Lv wrote:
Hi,
If no objection, I shall go on with the plan of instrument :)
Refer to Harmony status page[1], INSTRUMENT is missing, so this
module shall named as "instrument". I shall open a wiki-page for its
status l
Stepan Mishura wrote:
On 8/2/06, Jimmy, Jing Lv wrote:
Hi,
If no objection, I shall go on with the plan of instrument :)
Refer to Harmony status page[1], INSTRUMENT is missing, so this
module shall named as "instrument". I shall open a wiki-page for its
status like other modules on [2
Stepan Mishura wrote:
Yes, it is. But accoriding to [1] the code should be put into separate
'instrument' module.
So the patch should start with 'modules/'instrument'.
Ah ... you are right, thanks very much Stepan! :)
So I shall put code to
modules/
instrument/
src/main/java/java/l
Never appeal to me using a Wiki as an authority :) It's like finding
something written in chalk on the sidewalk.
However, if you had pointed out
http://incubator.apache.org/harmony/auth_cont_quest.html
I'd have agreed w/o having the opportunity to make fun of the Wiki.
So I agree :)
geir
Yes, it is. But accoriding to [1] the code should be put into separate
'instrument' module.
So the patch should start with 'modules/'instrument'.
Thanks,
Stepan.
[1]http://wiki.apache.org/harmony/componentization
On 8/2/06, Geir Magnusson Jr wrote:
It is a lang package, right?
Stepan Mishur
It is a lang package, right?
Stepan Mishura wrote:
> On 8/2/06, Jimmy, Jing Lv wrote:
>>
>> Hi,
>>
>> If no objection, I shall go on with the plan of instrument :)
>> Refer to Harmony status page[1], INSTRUMENT is missing, so this
>> module shall named as "instrument". I shall open a wiki
On 8/2/06, Jimmy, Jing Lv wrote:
Hi,
If no objection, I shall go on with the plan of instrument :)
Refer to Harmony status page[1], INSTRUMENT is missing, so this
module shall named as "instrument". I shall open a wiki-page for its
status like other modules on [2].
For Java codes,
Hi,
If no objection, I shall go on with the plan of instrument :)
Refer to Harmony status page[1], INSTRUMENT is missing, so this
module shall named as "instrument". I shall open a wiki-page for its
status like other modules on [2].
For Java codes, API classes/interfaces can be a
32 matches
Mail list logo
