JAXP RFR: 8000172 : 2 SAX features does not work properly

This is an issue found while I was working with SQE to expand test coverage. For a non-validating parser, when load-external-dtd is false, entity references are skipped. However, the skippedEntity() event was not reported. The problem was due to missing infoset augmentations when document han

Re: RFR: 7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently [sol]

Thanks Martin, Updated webrev at: http://cr.openjdk.java.net/~robm/7152183/webrev.03/ and a few comments inline: On 08/10/12 18:52, Martin Buchholz wrote: Thanks for the changes - this approach looks good. But: 1954

Re: 7173494: some jdk tests are not run in test/Makefile

On 08/10/2012 18:08, Chris Hegarty wrote: This update looks ok to me. At some point ( not asking you to do it now ) we will need to update 7u-dev, to avoid confusion around what tests are being run in what batches. Yes, I think this should go into jdk7u-dev too. -Alan

RE: 7173494: some jdk tests are not run in test/Makefile

> The webrev with the proposed changes is here: > http://cr.openjdk.java.net/~alanb/7173494/webrev/ Looks like a good clean-up. iris

Re: 7173494: some jdk tests are not run in test/Makefile

This looks like all good changes to me. Mike On Oct 7 2012, at 12:35 , Alan Bateman wrote: > > This one is a small clean-up of the test targets defined in > jdk/test/Makefile. The union of the tests executed by each of the make > targets should be the entire test suite but this isn't so, ther

Re: 7173494: some jdk tests are not run in test/Makefile

On 10/8/2012 11:12 AM, Alan Bateman wrote: On 08/10/2012 18:44, Mandy Chung wrote: It's good to clean this up and the change looks fine in general.A couple of minor comments: jdk_management - Might be good to include java/lang/management tests in this target in case someone only runs on

Re: 7173494: some jdk tests are not run in test/Makefile

On 08/10/2012 18:44, Mandy Chung wrote: It's good to clean this up and the change looks fine in general.A couple of minor comments: jdk_management - Might be good to include java/lang/management tests in this target in case someone only runs one target to verify that area. On the other h

Re: RFR: 7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently [sol]

Thanks for the changes - this approach looks good. But: 1954 case 0: r = s.read(bytes); break; 1955 case 2: r = s.read(bytes); break; The two cases are the same code; you want case 0: r = s.read(); break; 1964 Stri

Re: 7173494: some jdk tests are not run in test/Makefile

It's good to clean this up and the change looks fine in general.A couple of minor comments: jdk_management - Might be good to include java/lang/management tests in this target in case someone only runs one target to verify that area. On the other hands, they are currently covered by jdk_l

Re: 7173494: some jdk tests are not run in test/Makefile

This update looks ok to me. At some point ( not asking you to do it now ) we will need to update 7u-dev, to avoid confusion around what tests are being run in what batches. -Chris. On 07/10/2012 20:35, Alan Bateman wrote: This one is a small clean-up of the test targets defined in jdk/test/

Re: StackTraceElement question

FWIW, .Net's equivalent to this doesn't return the class but exposes the MethodBase (java.lang.reflect.Method analogous) that owns the frame and one can get the defining class from that. Sent from my phone On Oct 8, 2012 10:35 AM, "Krystal Mok" wrote: > On Mon, Oct 8, 2012 at 10:25 PM, Christos

Re: StackTraceElement question

On Mon, Oct 8, 2012 at 10:25 PM, Christos Zoulas wrote: > On Oct 8, 11:07pm, david.hol...@oracle.com (David Holmes) wrote: > -- Subject: Re: StackTraceElement question > > | > There is also the problem of having a class hierarchy like: > | > > | > class A extends class I > | > class B extends clas

Re: StackTraceElement question

StackTraceElement are Serializable and because they don't store any class, you can send an exception from the server back to the client without requiring that the client knows the classes loaded by the server. So at least, if the class is provided, this should be done optionally because the c

Re: StackTraceElement question

On Oct 8, 11:07pm, david.hol...@oracle.com (David Holmes) wrote: -- Subject: Re: StackTraceElement question | > There is also the problem of having a class hierarchy like: | > | > class A extends class I | > class B extends class I | > | > and then trying to figure out if it is A or B when you jus

Re: StackTraceElement question

On 8/10/2012 11:07 PM, David Holmes wrote: On 8/10/2012 9:48 PM, chris...@zoulas.com wrote: On Oct 8, 7:33pm, rednaxel...@gmail.com (Krystal Mok) wrote: -- Subject: Re: StackTraceElement question |> Can't you just do Class.forName(getClassName()) and then find the |> enclosing class? |> |> Ther

Re: StackTraceElement question

On 8/10/2012 9:48 PM, chris...@zoulas.com wrote: On Oct 8, 7:33pm, rednaxel...@gmail.com (Krystal Mok) wrote: -- Subject: Re: StackTraceElement question |> Can't you just do Class.forName(getClassName()) and then find the |> enclosing class? |> |> There could be potential class loader issues

Re: StackTraceElement question

On Oct 8, 7:33pm, rednaxel...@gmail.com (Krystal Mok) wrote: -- Subject: Re: StackTraceElement question | > Can't you just do Class.forName(getClassName()) and then find the | > enclosing class? | > | > There could be potential class loader issues to | use Class.forName(getClassName()) in this ca

Re: StackTraceElement question

On Mon, Oct 8, 2012 at 7:27 AM, David Holmes wrote: > On Sat, Oct 6, 2012 at 3:04 AM, Christos Zoulas >> wrote: >> >> Hi, >>> >>> I don't know if this belongs to this list, but if it does not, >>> please point me to where it does. I think that it would be nice if >>> StackTraceElement which curr