Discussion:
Review request for JDK-8051561: Convert JAXP function tests: javax.xml.xpath.* to jtreg (testNG) tests
Eric Wang
2014-07-25 13:12:27 UTC
Permalink
Hi Joe, alan and every one

I'm working on jaxp functional test colocation which is traced by the
bug JDK-8043091 <https://bugs.openjdk.java.net/browse/JDK-8043091>.
We have finished to convert a few suite and the jaxp/xpath tracked by
bug JDK-8051561 <https://bugs.openjdk.java.net/browse/JDK-8051561> is
the first one chosen for public review.

Can you please review the webrev below? your comments given would be
helpful for our future work.
http://cr.openjdk.java.net/~ewang/JDK-8051561/webrev.00/

Thanks,
Eric
roger riggs
2014-07-25 15:39:41 UTC
Permalink
Hi Eric,

A few comments:

- TestBase.java: 39: typo "Unexcepted" -> "Unexpected"

- TestUtils.java: 32: Consider moving XML_DIR to TestBase.java, it
seems similar to the other static final strings

- TestBase.java: 57,66; Is the extra starting/ending output useful for
TestNg Tests?
TestNg should already print a test header

- XPath<xxx>: note that TestNg will report any uncaught exception as a
failure;
it is not necessary to catch the exception and call fail().

- XPathFunctionResolver01: Nice use of Lambda :)

I realize these are ported tests and you may be keeping things as much
as possible to the existing tests.

Thanks, Roger
Post by Eric Wang
Hi Joe, alan and every one
I'm working on jaxp functional test colocation which is traced by the
bug JDK-8043091 <https://bugs.openjdk.java.net/browse/JDK-8043091>.
We have finished to convert a few suite and the jaxp/xpath tracked by
bug JDK-8051561 <https://bugs.openjdk.java.net/browse/JDK-8051561> is
the first one chosen for public review.
Can you please review the webrev below? your comments given would be
helpful for our future work.
http://cr.openjdk.java.net/~ewang/JDK-8051561/webrev.00/
Thanks,
Eric
huizhe wang
2014-07-28 05:42:40 UTC
Permalink
Hi Eric,

This is a good start! The code looks much more cleaner than the
previous tests, great work!

1. Base class
I see that you picked a small set of tests from the Product group
(a small surprise :-) since I thought you'd had the Auction-portal
group). You probably already considered it, but I assume there may be
three layers of base classes. By layers, I mean the following:
jaxp test
jaxp sqe
test unittests
astro auction portal gap product xslt


Each layer may have its own functions. For example, test groups
such as auction portal that used 3rd paty components may include
functions such as that you previously added to the auction portal test.

Furthermore, we've made it so that jaxp tests will run with/without
security manager. Frank and Patrick are adding such ability to the unit
tests. Could you work with them so that all of jaxp tests share the same
set of base classes including the functions in your base class, and
security/policy functions?

2. Unfinished tests
I see that you removed unfinished tests, e.g XPath01 test 39 - 51,
which reflected unimplemented feature. That's probably okay. Also
removed are test 09 to 12 from XPathFactory01 that were commented out
and moved to new test classes XPathFunctionResolver01 and
XPathVariableResolver01. Unfortunately, the later was never completed
due to the lose of the jaxp sqe engineer.

It's not in the scope of this project to develop new tests, but
could you leave a note somewhere in the tests?

3. Originally insufficient function test
Nice use of Lambda as Roger said :-)
If not for your clean-up, I wouldn't have noticed that the
XPathFunctionResolver simply returned null and XPathFuction was never
implemented. So it's not a surprise that there was indeed a bug in the
area (JDK-4946192 XPathFunctionResolver is not used).


Could you discuss with Jibing on what you may want to do in regards to
item 2 and 3 above? Patrick had previously increased test coverage. I
wonder if that would be something you would still consider.

Thanks,
Joe
Post by Eric Wang
Hi Joe, alan and every one
I'm working on jaxp functional test colocation which is traced by the
bug JDK-8043091 <https://bugs.openjdk.java.net/browse/JDK-8043091>.
We have finished to convert a few suite and the jaxp/xpath tracked by
bug JDK-8051561 <https://bugs.openjdk.java.net/browse/JDK-8051561> is
the first one chosen for public review.
Can you please review the webrev below? your comments given would be
helpful for our future work.
http://cr.openjdk.java.net/~ewang/JDK-8051561/webrev.00/
Thanks,
Eric
Tristan Yan
2014-08-18 17:46:35 UTC
Permalink
Hi Joe, Alan and others
We?re working on moving our internal jaxp functional tests to open idk repo(Include refactoring effort). This is the first open review I am asking for SAX and Transform. Would you please review these tests. Any comment will be appreciated.

I put the webrev as follows:
http://cr.openjdk.java.net/~tyan/JDK-8051540/webrev00/

Thank you very much.
Tristan
huizhe wang
2014-08-18 23:32:09 UTC
Permalink
Hi Tristan,

Nice work! As with those converted by Eric (8051561), the new tests
looked much better and cleaner than the original ones.

I see that you're using jaxp.library instead of a base class as in
Eric's previous webrev. Is this the final decision on the whole test
structure? It looks good.

Have you run them with and without security manager?

Thanks,
Joe
Post by Tristan Yan
Hi Joe, Alan and others
We?re working on moving our internal jaxp functional tests to open idk
repo(Include refactoring effort). This is the first open review I am
asking for SAX and Transform. Would you please review these tests. Any
comment will be appreciated.
http://cr.openjdk.java.net/~tyan/JDK-8051540/webrev00/
<http://cr.openjdk.java.net/%7Etyan/JDK-8051540/webrev00/>
Thank you very much.
Tristan
Tristan Yan
2014-08-18 23:42:56 UTC
Permalink
Thanks Joe
We intend to replace the base class with test library because that doesn?t look like a real base class but an utilities class.
I haven?t tried to run these tests with security manager, I will run them with security manager then get back you soon.
Thank you.
Tristan
huizhe wang
2014-08-19 17:32:22 UTC
Permalink
By the way, the plan has been that all of the JAXP SQE and Unit tests be
migrated into [openjdk]/jaxp repo under jaxp/test. Tests currently in
the jdk repo shall be moved to jaxp/test as well. I see that your webrev
was generated in jdk9/dev/jdk. I hope it doesn't mean you're checking
tests into the jdk repo.

Thanks,
Joe
Post by Tristan Yan
Thanks Joe
We intend to replace the base class with test library because that
doesn?t look like a real base class but an utilities class.
I haven?t tried to run these tests with security manager, I will run
them with security manager then get back you soon.
Thank you.
Tristan
On Aug 18, 2014, at 4:32 PM, huizhe wang <huizhe.wang at oracle.com
Tristan Yan
2014-08-19 17:34:40 UTC
Permalink
Thanks Joe.
I will move the tests to [openjdk]/jaxp repo then.
Tristan
By the way, the plan has been that all of the JAXP SQE and Unit tests be migrated into [openjdk]/jaxp repo under jaxp/test. Tests currently in the jdk repo shall be moved to jaxp/test as well. I see that your webrev was generated in jdk9/dev/jdk. I hope it doesn't mean you're checking tests into the jdk repo.
Thanks,
Joe
Post by Tristan Yan
Thanks Joe
We intend to replace the base class with test library because that doesn?t look like a real base class but an utilities class.
I haven?t tried to run these tests with security manager, I will run them with security manager then get back you soon.
Thank you.
Tristan
Tristan Yan
2014-08-27 23:03:21 UTC
Permalink
Hi Joe and others

I updated the tests with putting them in jaxp repo. I also run these tests with security manager and they all passed
http://cr.openjdk.java.net/~tyan/JDK-8051540/webrev01/ <http://cr.openjdk.java.net/~tyan/JDK-8051540/webrev01/>

Also I?d like to propose our way for handling jaxp tests run with security manager. The way we?d use is creating two targets for running jaxp tests. One is for normal run; which will run all the tests without security manager. One is secure run; the target only run the tests that have to be run with security manager. This could be easy to be handled with adding two targets in makefile. And for most of people they only care about the function. They only need run normal run target. We would run two targets for any of our formal tests like nightly, ci build and jprt tests.
For the tests which can not be run in secure mode(like tests for xsltc direct extension), we'd add testng group called ?secure-hostile?. We won?t run these tests in secure mode by bypassing them in secure run target. By this way we could easily transform our tests as usual without additional effort.

Thank you
Tristan
By the way, the plan has been that all of the JAXP SQE and Unit tests be migrated into [openjdk]/jaxp repo under jaxp/test. Tests currently in the jdk repo shall be moved to jaxp/test as well. I see that your webrev was generated in jdk9/dev/jdk. I hope it doesn't mean you're checking tests into the jdk repo.
Thanks,
Joe
Post by Tristan Yan
Thanks Joe
We intend to replace the base class with test library because that doesn?t look like a real base class but an utilities class.
I haven?t tried to run these tests with security manager, I will run them with security manager then get back you soon.
Thank you.
Tristan
huizhe wang
2014-08-27 23:38:33 UTC
Permalink
Post by Tristan Yan
Hi Joe and others
I updated the tests with putting them in jaxp repo. I also run these
tests with security manager and they all passed
http://cr.openjdk.java.net/~tyan/JDK-8051540/webrev01/
<http://cr.openjdk.java.net/%7Etyan/JDK-8051540/webrev01/>
Awesome.
Post by Tristan Yan
Also I?d like to propose our way for handling jaxp tests run with
security manager. The way we?d use is creating two targets for
running jaxp tests. One is for normal run; which will run all the
tests without security manager. One is secure run; the target only run
the tests that have to be run with security manager. This could be
easy to be handled with adding two targets in makefile. And for most
of people they only care about the function. They only need run normal
run target. We would run two targets for any of our formal tests like
nightly, ci build and jprt tests.
Yes, please coordinate with Frank and Eric so that all of the jaxp tests
share the same configuration.
Post by Tristan Yan
For the tests which can not be run in secure mode(like tests for xsltc
direct extension), we'd add testng group called ?secure-hostile?. We
won?t run these tests in secure mode by bypassing them in secure run
target. By this way we could easily transform our tests as usual
without additional effort.
I had been previously updated them so that all of the tests were capable
of running with and without security manager. Sustaining SQE had
invested several month to incorporate the changes into that hosted in
Aurora. Please consider taking the patches from them if you haven't
already done so.

Thanks,
Joe
Post by Tristan Yan
Thank you
Tristan
On Aug 19, 2014, at 10:32 AM, huizhe wang <huizhe.wang at oracle.com
By the way, the plan has been that all of the JAXP SQE and Unit tests
be migrated into [openjdk]/jaxp repo under jaxp/test. Tests currently
in the jdk repo shall be moved to jaxp/test as well. I see that your
webrev was generated in jdk9/dev/jdk. I hope it doesn't mean you're
checking tests into the jdk repo.
Thanks,
Joe
Post by Tristan Yan
Thanks Joe
We intend to replace the base class with test library because that
doesn?t look like a real base class but an utilities class.
I haven?t tried to run these tests with security manager, I will run
them with security manager then get back you soon.
Thank you.
Tristan
On Aug 18, 2014, at 4:32 PM, huizhe wang <huizhe.wang at oracle.com
Frank Yuan
2014-08-28 03:42:31 UTC
Permalink
Hi Joe



The test Tristan mentioned that is unable to run with security manager is http://sqe-hgi.us.oracle.com/hg/index.cgi/testbase/javase/functional/9/xml/file/3f7ae9b99933/src/JAXP/unittests/unit-test/bug6513892 , it is used to test xslt redirect extension. When it runs with security manager, fails due to;

java.lang.RuntimeException: Use of the extension element 'redirect' is not allowed when the secure processing feature is set to true.



Anyway, Jibing would communicate with sustaining team about their patch, the discussion is in another mail chain.



Best Regards

Frank





-----Original Message-----
From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of huizhe wang
Sent: Thursday, August 28, 2014 7:39 AM
To: Tristan Yan
Cc: Core-Libs-Dev
Subject: Re: Review request for JDK-8051540: Convert JAXP functin tests: org.xml.sax to jtreg (testNG) tests
Post by Tristan Yan
Hi Joe and others
I updated the tests with putting them in jaxp repo. I also run these
tests with security manager and they all passed
<http://cr.openjdk.java.net/~tyan/JDK-8051540/webrev01/> http://cr.openjdk.java.net/~tyan/JDK-8051540/webrev01/
< <http://cr.openjdk.java.net/%7Etyan/JDK-8051540/webrev01/> http://cr.openjdk.java.net/%7Etyan/JDK-8051540/webrev01/>
Awesome.
Post by Tristan Yan
Also I?d like to propose our way for handling jaxp tests run with
security manager. The way we?d use is creating two targets for
running jaxp tests. One is for normal run; which will run all the
tests without security manager. One is secure run; the target only run
the tests that have to be run with security manager. This could be
easy to be handled with adding two targets in makefile. And for most
of people they only care about the function. They only need run normal
run target. We would run two targets for any of our formal tests like
nightly, ci build and jprt tests.
Yes, please coordinate with Frank and Eric so that all of the jaxp tests share the same configuration.
Post by Tristan Yan
For the tests which can not be run in secure mode(like tests for xsltc
direct extension), we'd add testng group called ?secure-hostile?. We
won?t run these tests in secure mode by bypassing them in secure run
target. By this way we could easily transform our tests as usual
without additional effort.
I had been previously updated them so that all of the tests were capable of running with and without security manager. Sustaining SQE had invested several month to incorporate the changes into that hosted in Aurora. Please consider taking the patches from them if you haven't already done so.



Thanks,

Joe
Post by Tristan Yan
Thank you
Tristan
On Aug 19, 2014, at 10:32 AM, huizhe wang <huizhe.wang at oracle.com
By the way, the plan has been that all of the JAXP SQE and Unit tests
be migrated into [openjdk]/jaxp repo under jaxp/test. Tests currently
in the jdk repo shall be moved to jaxp/test as well. I see that your
webrev was generated in jdk9/dev/jdk. I hope it doesn't mean you're
checking tests into the jdk repo.
Thanks,
Joe
Post by Tristan Yan
Thanks Joe
We intend to replace the base class with test library because that
doesn?t look like a real base class but an utilities class.
I haven?t tried to run these tests with security manager, I will run
them with security manager then get back you soon.
Thank you.
Tristan
On Aug 18, 2014, at 4:32 PM, huizhe wang <huizhe.wang at oracle.com
huizhe wang
2014-08-28 03:48:03 UTC
Permalink
The patches I mentioned would disable security manager or grant specific
permissions needed to run those code, so that no test needs to be
excluded from a target (whether with or without security manager).

Thanks,
Joe
Post by Eric Wang
Hi Joe
The test Tristan mentioned that is unable to run with security manager
is
http://sqe-hgi.us.oracle.com/hg/index.cgi/testbase/javase/functional/9/xml/file/3f7ae9b99933/src/JAXP/unittests/unit-test/bug6513892
, it is used to test xslt redirect extension. When it runs with
security manager, fails due to;
/java.lang.RuntimeException: Use of the extension element 'redirect'
is not allowed when the secure processing feature is set to true./
Anyway, Jibing would communicate with sustaining team about their
patch, the discussion is in another mail chain.
Best Regards
Frank
-----Original Message-----
From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
Behalf Of huizhe wang
Sent: Thursday, August 28, 2014 7:39 AM
To: Tristan Yan
Cc: Core-Libs-Dev
Subject: Re: Review request for JDK-8051540: Convert JAXP functin
tests: org.xml.sax to jtreg (testNG) tests
Post by Tristan Yan
Hi Joe and others
I updated the tests with putting them in jaxp repo. I also run these
tests with security manager and they all passed
http://cr.openjdk.java.net/~tyan/JDK-8051540/webrev01/
<http://cr.openjdk.java.net/%7Etyan/JDK-8051540/webrev01/>
Post by Tristan Yan
<http://cr.openjdk.java.net/%7Etyan/JDK-8051540/webrev01/>
Awesome.
Post by Tristan Yan
Also I?d like to propose our way for handling jaxp tests run with
security manager. The way we?d use is creating two targets for
running jaxp tests. One is for normal run; which will run all the
tests without security manager. One is secure run; the target only run
the tests that have to be run with security manager. This could be
easy to be handled with adding two targets in makefile. And for most
of people they only care about the function. They only need run normal
run target. We would run two targets for any of our formal tests like
nightly, ci build and jprt tests.
Yes, please coordinate with Frank and Eric so that all of the jaxp
tests share the same configuration.
Post by Tristan Yan
For the tests which can not be run in secure mode(like tests for xsltc
direct extension), we'd add testng group called ?secure-hostile?. We
won?t run these tests in secure mode by bypassing them in secure run
target. By this way we could easily transform our tests as usual
without additional effort.
I had been previously updated them so that all of the tests were
capable of running with and without security manager. Sustaining SQE
had invested several month to incorporate the changes into that hosted
in Aurora. Please consider taking the patches from them if you haven't
already done so.
Thanks,
Joe
Post by Tristan Yan
Thank you
Tristan
On Aug 19, 2014, at 10:32 AM, huizhe wang <huizhe.wang at oracle.com
By the way, the plan has been that all of the JAXP SQE and Unit tests
be migrated into [openjdk]/jaxp repo under jaxp/test. Tests currently
in the jdk repo shall be moved to jaxp/test as well. I see that your
webrev was generated in jdk9/dev/jdk. I hope it doesn't mean you're
checking tests into the jdk repo.
Thanks,
Joe
Post by Tristan Yan
Thanks Joe
We intend to replace the base class with test library because that
doesn?t look like a real base class but an utilities class.
I haven?t tried to run these tests with security manager, I will run
them with security manager then get back you soon.
Thank you.
Tristan
On Aug 18, 2014, at 4:32 PM, huizhe wang <huizhe.wang at oracle.com
Michael Kay
2014-08-28 07:31:07 UTC
Permalink
I haven't yet had a chance to look at the JAXP tests, but this kind of message suggests to me that they don't separate what is in JAXP (the interface) from what is in Xalan and Xerces (the implementations).Would that be a correct assumption? The "redirect" extension is not a JAXP feature, it is a Xalan feature.

I've had the impression for some years that the management of JAXP as an interface is far too closely tied up with the management of the JAXP implementations within the JDK.

Michael Kay
Saxonica
mike at saxonica.com
+44 (0) 118 946 5893
Post by Eric Wang
Hi Joe
The test Tristan mentioned that is unable to run with security manager is http://sqe-hgi.us.oracle.com/hg/index.cgi/testbase/javase/functional/9/xml/file/3f7ae9b99933/src/JAXP/unittests/unit-test/bug6513892 , it is used to test xslt redirect extension. When it runs with security manager, fails due to;
java.lang.RuntimeException: Use of the extension element 'redirect' is not allowed when the secure processing feature is set to true.
Anyway, Jibing would communicate with sustaining team about their patch, the discussion is in another mail chain.
Best Regards
Frank
-----Original Message-----
From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of huizhe wang
Sent: Thursday, August 28, 2014 7:39 AM
To: Tristan Yan
Cc: Core-Libs-Dev
Subject: Re: Review request for JDK-8051540: Convert JAXP functin tests: org.xml.sax to jtreg (testNG) tests
Post by Tristan Yan
Hi Joe and others
I updated the tests with putting them in jaxp repo. I also run these
tests with security manager and they all passed
<http://cr.openjdk.java.net/~tyan/JDK-8051540/webrev01/> http://cr.openjdk.java.net/~tyan/JDK-8051540/webrev01/
< <http://cr.openjdk.java.net/%7Etyan/JDK-8051540/webrev01/> http://cr.openjdk.java.net/%7Etyan/JDK-8051540/webrev01/>
Awesome.
Post by Tristan Yan
Also I?d like to propose our way for handling jaxp tests run with
security manager. The way we?d use is creating two targets for
running jaxp tests. One is for normal run; which will run all the
tests without security manager. One is secure run; the target only run
the tests that have to be run with security manager. This could be
easy to be handled with adding two targets in makefile. And for most
of people they only care about the function. They only need run normal
run target. We would run two targets for any of our formal tests like
nightly, ci build and jprt tests.
Yes, please coordinate with Frank and Eric so that all of the jaxp tests share the same configuration.
Post by Tristan Yan
For the tests which can not be run in secure mode(like tests for xsltc
direct extension), we'd add testng group called ?secure-hostile?. We
won?t run these tests in secure mode by bypassing them in secure run
target. By this way we could easily transform our tests as usual
without additional effort.
I had been previously updated them so that all of the tests were capable of running with and without security manager. Sustaining SQE had invested several month to incorporate the changes into that hosted in Aurora. Please consider taking the patches from them if you haven't already done so.
Thanks,
Joe
Post by Tristan Yan
Thank you
Tristan
On Aug 19, 2014, at 10:32 AM, huizhe wang <huizhe.wang at oracle.com
By the way, the plan has been that all of the JAXP SQE and Unit tests
be migrated into [openjdk]/jaxp repo under jaxp/test. Tests currently
in the jdk repo shall be moved to jaxp/test as well. I see that your
webrev was generated in jdk9/dev/jdk. I hope it doesn't mean you're
checking tests into the jdk repo.
Thanks,
Joe
Post by Tristan Yan
Thanks Joe
We intend to replace the base class with test library because that
doesn?t look like a real base class but an utilities class.
I haven?t tried to run these tests with security manager, I will run
them with security manager then get back you soon.
Thank you.
Tristan
On Aug 18, 2014, at 4:32 PM, huizhe wang <huizhe.wang at oracle.com
Frank Yuan
2014-08-28 08:45:49 UTC
Permalink
Hi, Michael

Secure processing feature(XMLConstants.FEATURE_SECURE_PROCESSING) is also
valid for transform API(Xalan). And the transform API is a portion of JAXP.

To Joe

Please correct me if I am wrong.

Best Regards
Frank

-----Original Message-----
From: Michael Kay [mailto:mike at saxonica.com]
Sent: Thursday, August 28, 2014 3:31 PM
To: Frank Yuan
Cc: huizhe wang; Tristan Yan; Core-Libs-Dev
Subject: Re: Review request for JDK-8051540: Convert JAXP functin tests:
org.xml.sax to jtreg (testNG) tests

I haven't yet had a chance to look at the JAXP tests, but this kind of
message suggests to me that they don't separate what is in JAXP (the
interface) from what is in Xalan and Xerces (the implementations).Would that
be a correct assumption? The "redirect" extension is not a JAXP feature, it
is a Xalan feature.

I've had the impression for some years that the management of JAXP as an
interface is far too closely tied up with the management of the JAXP
implementations within the JDK.

Michael Kay
Saxonica
mike at saxonica.com <mailto:mike at saxonica.com>
+44 (0) 118 946 5893




On 28 Aug 2014, at 04:42, Frank Yuan <frank.yuan at oracle.com
Post by Eric Wang
Hi Joe
The test Tristan mentioned that is unable to run with security manager is
bug6513892
<http://sqe-hgi.us.oracle.com/hg/index.cgi/testbase/javase/functional/9/xml/
file/3f7ae9b99933/src/JAXP/unittests/unit-test/bug6513892> , it is used to
test xslt redirect extension. When it runs with security manager, fails due
to;
Post by Eric Wang
java.lang.RuntimeException: Use of the extension element 'redirect' is not
allowed when the secure processing feature is set to true.
Post by Eric Wang
Anyway, Jibing would communicate with sustaining team about their patch,
the discussion is in another mail chain.
Post by Eric Wang
Best Regards
Frank
-----Original Message-----
From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
Behalf Of huizhe wang
Post by Eric Wang
Sent: Thursday, August 28, 2014 7:39 AM
To: Tristan Yan
Cc: Core-Libs-Dev
org.xml.sax to jtreg (testNG) tests
Post by Eric Wang
Post by Tristan Yan
Hi Joe and others
I updated the tests with putting them in jaxp repo. I also run these
tests with security manager and they all passed
<http://cr.openjdk.java.net/~tyan/JDK-8051540/webrev01/>
http://cr.openjdk.java.net/~tyan/JDK-8051540/webrev01/
Post by Eric Wang
Post by Tristan Yan
< <http://cr.openjdk.java.net/%7Etyan/JDK-8051540/webrev01/>
http://cr.openjdk.java.net/%7Etyan/JDK-8051540/webrev01/>
Post by Eric Wang
Awesome.
Post by Tristan Yan
Also I'd like to propose our way for handling jaxp tests run with
security manager. The way we'd use is creating two targets for
running jaxp tests. One is for normal run; which will run all the
tests without security manager. One is secure run; the target only run
the tests that have to be run with security manager. This could be
easy to be handled with adding two targets in makefile. And for most
of people they only care about the function. They only need run normal
run target. We would run two targets for any of our formal tests like
nightly, ci build and jprt tests.
Yes, please coordinate with Frank and Eric so that all of the jaxp tests
share the same configuration.
Post by Eric Wang
Post by Tristan Yan
For the tests which can not be run in secure mode(like tests for xsltc
direct extension), we'd add testng group called "secure-hostile". We
won't run these tests in secure mode by bypassing them in secure run
target. By this way we could easily transform our tests as usual
without additional effort.
I had been previously updated them so that all of the tests were capable
of running with and without security manager. Sustaining SQE had invested
several month to incorporate the changes into that hosted in Aurora. Please
consider taking the patches from them if you haven't already done so.
Post by Eric Wang
Thanks,
Joe
Post by Tristan Yan
Thank you
Tristan
On Aug 19, 2014, at 10:32 AM, huizhe wang <huizhe.wang at oracle.com
By the way, the plan has been that all of the JAXP SQE and Unit tests
be migrated into [openjdk]/jaxp repo under jaxp/test. Tests currently
in the jdk repo shall be moved to jaxp/test as well. I see that your
webrev was generated in jdk9/dev/jdk. I hope it doesn't mean you're
checking tests into the jdk repo.
Thanks,
Joe
Post by Tristan Yan
Thanks Joe
We intend to replace the base class with test library because that
doesn't look like a real base class but an utilities class.
I haven't tried to run these tests with security manager, I will run
them with security manager then get back you soon.
Thank you.
Tristan
On Aug 18, 2014, at 4:32 PM, huizhe wang <huizhe.wang at oracle.com
huizhe wang
2014-08-28 20:22:59 UTC
Permalink
Hi Michael,

These are functional and unit tests. They reflect what are supported by
the JDK. So yes, you are right, a good portion of them are relevant to
the implementation.

If you are looking for pure JAXP API tests, you'd find them in the JCK.

Thanks,
Joe
Post by Michael Kay
I haven't yet had a chance to look at the JAXP tests, but this kind of message suggests to me that they don't separate what is in JAXP (the interface) from what is in Xalan and Xerces (the implementations).Would that be a correct assumption? The "redirect" extension is not a JAXP feature, it is a Xalan feature.
I've had the impression for some years that the management of JAXP as an interface is far too closely tied up with the management of the JAXP implementations within the JDK.
Michael Kay
Saxonica
mike at saxonica.com
+44 (0) 118 946 5893
Post by Eric Wang
Hi Joe
The test Tristan mentioned that is unable to run with security manager is http://sqe-hgi.us.oracle.com/hg/index.cgi/testbase/javase/functional/9/xml/file/3f7ae9b99933/src/JAXP/unittests/unit-test/bug6513892 , it is used to test xslt redirect extension. When it runs with security manager, fails due to;
java.lang.RuntimeException: Use of the extension element 'redirect' is not allowed when the secure processing feature is set to true.
Anyway, Jibing would communicate with sustaining team about their patch, the discussion is in another mail chain.
Best Regards
Frank
-----Original Message-----
From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of huizhe wang
Sent: Thursday, August 28, 2014 7:39 AM
To: Tristan Yan
Cc: Core-Libs-Dev
Subject: Re: Review request for JDK-8051540: Convert JAXP functin tests: org.xml.sax to jtreg (testNG) tests
Post by Tristan Yan
Hi Joe and others
I updated the tests with putting them in jaxp repo. I also run these
tests with security manager and they all passed
<http://cr.openjdk.java.net/~tyan/JDK-8051540/webrev01/> http://cr.openjdk.java.net/~tyan/JDK-8051540/webrev01/
< <http://cr.openjdk.java.net/%7Etyan/JDK-8051540/webrev01/> http://cr.openjdk.java.net/%7Etyan/JDK-8051540/webrev01/>
Awesome.
Post by Tristan Yan
Also I?d like to propose our way for handling jaxp tests run with
security manager. The way we?d use is creating two targets for
running jaxp tests. One is for normal run; which will run all the
tests without security manager. One is secure run; the target only run
the tests that have to be run with security manager. This could be
easy to be handled with adding two targets in makefile. And for most
of people they only care about the function. They only need run normal
run target. We would run two targets for any of our formal tests like
nightly, ci build and jprt tests.
Yes, please coordinate with Frank and Eric so that all of the jaxp tests share the same configuration.
Post by Tristan Yan
For the tests which can not be run in secure mode(like tests for xsltc
direct extension), we'd add testng group called ?secure-hostile?. We
won?t run these tests in secure mode by bypassing them in secure run
target. By this way we could easily transform our tests as usual
without additional effort.
I had been previously updated them so that all of the tests were capable of running with and without security manager. Sustaining SQE had invested several month to incorporate the changes into that hosted in Aurora. Please consider taking the patches from them if you haven't already done so.
Thanks,
Joe
Post by Tristan Yan
Thank you
Tristan
On Aug 19, 2014, at 10:32 AM, huizhe wang <huizhe.wang at oracle.com
By the way, the plan has been that all of the JAXP SQE and Unit tests
be migrated into [openjdk]/jaxp repo under jaxp/test. Tests currently
in the jdk repo shall be moved to jaxp/test as well. I see that your
webrev was generated in jdk9/dev/jdk. I hope it doesn't mean you're
checking tests into the jdk repo.
Thanks,
Joe
Post by Tristan Yan
Thanks Joe
We intend to replace the base class with test library because that
doesn?t look like a real base class but an utilities class.
I haven?t tried to run these tests with security manager, I will run
them with security manager then get back you soon.
Thank you.
Tristan
On Aug 18, 2014, at 4:32 PM, huizhe wang <huizhe.wang at oracle.com
Alan Bateman
2014-08-29 08:00:57 UTC
Permalink
Post by Michael Kay
I haven't yet had a chance to look at the JAXP tests, but this kind of message suggests to me that they don't separate what is in JAXP (the interface) from what is in Xalan and Xerces (the implementations).Would that be a correct assumption? The "redirect" extension is not a JAXP feature, it is a Xalan feature.
I've had the impression for some years that the management of JAXP as an interface is far too closely tied up with the management of the JAXP implementations within the JDK.
Just to add to Joe's comments then it is important to have a
comprehensive set of tests that fully exercise the implementation and
any JDK-specific implementation features. Clearly conformance tests for
the JAXP API should only have tests that are developed based on the
specification but that is the role of the conformance suite/JCK (which
is not in OpenJDK).

-Alan.
Tristan Yan
2014-10-14 22:10:09 UTC
Permalink
Hi Joe
Could you be my sponsor to push this if you?re okay with the code.
Thank you
Tristan
Post by huizhe wang
Post by Tristan Yan
Hi Joe and others
I updated the tests with putting them in jaxp repo. I also run these tests with security manager and they all passed
http://cr.openjdk.java.net/~tyan/JDK-8051540/webrev01/ <http://cr.openjdk.java.net/%7Etyan/JDK-8051540/webrev01/>
Awesome.
Post by Tristan Yan
Also I?d like to propose our way for handling jaxp tests run with security manager. The way we?d use is creating two targets for running jaxp tests. One is for normal run; which will run all the tests without security manager. One is secure run; the target only run the tests that have to be run with security manager. This could be easy to be handled with adding two targets in makefile. And for most of people they only care about the function. They only need run normal run target. We would run two targets for any of our formal tests like nightly, ci build and jprt tests.
Yes, please coordinate with Frank and Eric so that all of the jaxp tests share the same configuration.
Post by Tristan Yan
For the tests which can not be run in secure mode(like tests for xsltc direct extension), we'd add testng group called ?secure-hostile?. We won?t run these tests in secure mode by bypassing them in secure run target. By this way we could easily transform our tests as usual without additional effort.
I had been previously updated them so that all of the tests were capable of running with and without security manager. Sustaining SQE had invested several month to incorporate the changes into that hosted in Aurora. Please consider taking the patches from them if you haven't already done so.
Thanks,
Joe
Post by Tristan Yan
Thank you
Tristan
By the way, the plan has been that all of the JAXP SQE and Unit tests be migrated into [openjdk]/jaxp repo under jaxp/test. Tests currently in the jdk repo shall be moved to jaxp/test as well. I see that your webrev was generated in jdk9/dev/jdk. I hope it doesn't mean you're checking tests into the jdk repo.
Thanks,
Joe
Post by Tristan Yan
Thanks Joe
We intend to replace the base class with test library because that doesn?t look like a real base class but an utilities class.
I haven?t tried to run these tests with security manager, I will run them with security manager then get back you soon.
Thank you.
Tristan
huizhe wang
2014-10-15 08:43:49 UTC
Permalink
Joe,

You mentioned recently that you were considering folding the jaxp repo
into some other repos. Would it matter if we put these functional tests
into the existing jaxp repo (<openjdk forest>/jaxp/test)? Or, would jaxp
tests be under whatever the 'other' repo is?

We had planned to migrate jaxp unit and functional tests to jaxp
repo/test, and then move jaxp tests currently under jdk/test to
jaxp/test as well.

These patches are big. I hope we don't have to move them around :-)

Thanks,
Joe
Post by Eric Wang
Hi Joe
Could you be my sponsor to push this if you?re okay with the code.
Thank you
Tristan
On Aug 27, 2014, at 4:38 PM, huizhe wang <huizhe.wang at oracle.com
Post by Tristan Yan
Hi Joe and others
I updated the tests with putting them in jaxp repo. I also run these
tests with security manager and they all passed
http://cr.openjdk.java.net/~tyan/JDK-8051540/webrev01/
<http://cr.openjdk.java.net/%7Etyan/JDK-8051540/webrev01/>
Awesome.
Post by Tristan Yan
Also I?d like to propose our way for handling jaxp tests run with
security manager. The way we?d use is creating two targets for
running jaxp tests. One is for normal run; which will run all the
tests without security manager. One is secure run; the target only
run the tests that have to be run with security manager. This could
be easy to be handled with adding two targets in makefile. And for
most of people they only care about the function. They only need run
normal run target. We would run two targets for any of our formal
tests like nightly, ci build and jprt tests.
Yes, please coordinate with Frank and Eric so that all of the jaxp
tests share the same configuration.
Post by Tristan Yan
For the tests which can not be run in secure mode(like tests for
xsltc direct extension), we'd add testng group called
?secure-hostile?. We won?t run these tests in secure mode by
bypassing them in secure run target. By this way we could easily
transform our tests as usual without additional effort.
I had been previously updated them so that all of the tests were
capable of running with and without security manager. Sustaining SQE
had invested several month to incorporate the changes into that
hosted in Aurora. Please consider taking the patches from them if you
haven't already done so.
Thanks,
Joe
Post by Tristan Yan
Thank you
Tristan
On Aug 19, 2014, at 10:32 AM, huizhe wang <huizhe.wang at oracle.com
By the way, the plan has been that all of the JAXP SQE and Unit
tests be migrated into [openjdk]/jaxp repo under jaxp/test. Tests
currently in the jdk repo shall be moved to jaxp/test as well. I
see that your webrev was generated in jdk9/dev/jdk. I hope it
doesn't mean you're checking tests into the jdk repo.
Thanks,
Joe
Post by Tristan Yan
Thanks Joe
We intend to replace the base class with test library because that
doesn?t look like a real base class but an utilities class.
I haven?t tried to run these tests with security manager, I will
run them with security manager then get back you soon.
Thank you.
Tristan
On Aug 18, 2014, at 4:32 PM, huizhe wang <huizhe.wang at oracle.com
Joe Darcy
2014-10-15 15:35:39 UTC
Permalink
Hi Joe,

Before performing the full investigation, I'm now leaning toward have a
"base" repo which would host files currently in the jdk, langtools, and
hotspot repos and then another repo for all the other library code
(jaxp, jaxws, corba).

Compared to moving around all the source files in the jdk repo, I think
the other potential changes are fairly small!

HTH,

-Joe
Post by huizhe wang
Joe,
You mentioned recently that you were considering folding the jaxp repo
into some other repos. Would it matter if we put these functional
tests into the existing jaxp repo (<openjdk forest>/jaxp/test)? Or,
would jaxp tests be under whatever the 'other' repo is?
We had planned to migrate jaxp unit and functional tests to jaxp
repo/test, and then move jaxp tests currently under jdk/test to
jaxp/test as well.
These patches are big. I hope we don't have to move them around :-)
Thanks,
Joe
Post by Eric Wang
Hi Joe
Could you be my sponsor to push this if you?re okay with the code.
Thank you
Tristan
On Aug 27, 2014, at 4:38 PM, huizhe wang <huizhe.wang at oracle.com
Post by Tristan Yan
Hi Joe and others
I updated the tests with putting them in jaxp repo. I also run
these tests with security manager and they all passed
http://cr.openjdk.java.net/~tyan/JDK-8051540/webrev01/
<http://cr.openjdk.java.net/%7Etyan/JDK-8051540/webrev01/>
Awesome.
Post by Tristan Yan
Also I?d like to propose our way for handling jaxp tests run with
security manager. The way we?d use is creating two targets for
running jaxp tests. One is for normal run; which will run all the
tests without security manager. One is secure run; the target only
run the tests that have to be run with security manager. This could
be easy to be handled with adding two targets in makefile. And for
most of people they only care about the function. They only need
run normal run target. We would run two targets for any of our
formal tests like nightly, ci build and jprt tests.
Yes, please coordinate with Frank and Eric so that all of the jaxp
tests share the same configuration.
Post by Tristan Yan
For the tests which can not be run in secure mode(like tests for
xsltc direct extension), we'd add testng group called
?secure-hostile?. We won?t run these tests in secure mode by
bypassing them in secure run target. By this way we could easily
transform our tests as usual without additional effort.
I had been previously updated them so that all of the tests were
capable of running with and without security manager. Sustaining SQE
had invested several month to incorporate the changes into that
hosted in Aurora. Please consider taking the patches from them if
you haven't already done so.
Thanks,
Joe
Post by Tristan Yan
Thank you
Tristan
On Aug 19, 2014, at 10:32 AM, huizhe wang <huizhe.wang at oracle.com
By the way, the plan has been that all of the JAXP SQE and Unit
tests be migrated into [openjdk]/jaxp repo under jaxp/test. Tests
currently in the jdk repo shall be moved to jaxp/test as well. I
see that your webrev was generated in jdk9/dev/jdk. I hope it
doesn't mean you're checking tests into the jdk repo.
Thanks,
Joe
Post by Tristan Yan
Thanks Joe
We intend to replace the base class with test library because
that doesn?t look like a real base class but an utilities class.
I haven?t tried to run these tests with security manager, I will
run them with security manager then get back you soon.
Thank you.
Tristan
On Aug 18, 2014, at 4:32 PM, huizhe wang <huizhe.wang at oracle.com
huizhe wang
2014-10-15 18:09:03 UTC
Permalink
Post by Eric Wang
Hi Joe,
Before performing the full investigation, I'm now leaning toward have
a "base" repo which would host files currently in the jdk, langtools,
and hotspot repos and then another repo for all the other library code
(jaxp, jaxws, corba).
Something like this?
otherlib repo/
jaxp/src and etc.
jaxws
corba

Currently, we are enjoying the benefit of being a repo by itself, that
is, using the whole repo as our workspace.
But I understand the need for consolidating, as long as it's in its own
root directory, I think it would be fine.
Post by Eric Wang
Compared to moving around all the source files in the jdk repo, I
think the other potential changes are fairly small!
True, I'll push the change then.

Thanks!
Joe
Post by Eric Wang
HTH,
-Joe
Post by huizhe wang
Joe,
You mentioned recently that you were considering folding the jaxp
repo into some other repos. Would it matter if we put these
functional tests into the existing jaxp repo (<openjdk
forest>/jaxp/test)? Or, would jaxp tests be under whatever the
'other' repo is?
We had planned to migrate jaxp unit and functional tests to jaxp
repo/test, and then move jaxp tests currently under jdk/test to
jaxp/test as well.
These patches are big. I hope we don't have to move them around :-)
Thanks,
Joe
Post by Eric Wang
Hi Joe
Could you be my sponsor to push this if you?re okay with the code.
Thank you
Tristan
On Aug 27, 2014, at 4:38 PM, huizhe wang <huizhe.wang at oracle.com
Post by Tristan Yan
Hi Joe and others
I updated the tests with putting them in jaxp repo. I also run
these tests with security manager and they all passed
http://cr.openjdk.java.net/~tyan/JDK-8051540/webrev01/
<http://cr.openjdk.java.net/%7Etyan/JDK-8051540/webrev01/>
Awesome.
Post by Tristan Yan
Also I?d like to propose our way for handling jaxp tests run with
security manager. The way we?d use is creating two targets for
running jaxp tests. One is for normal run; which will run all the
tests without security manager. One is secure run; the target only
run the tests that have to be run with security manager. This
could be easy to be handled with adding two targets in makefile.
And for most of people they only care about the function. They
only need run normal run target. We would run two targets for any
of our formal tests like nightly, ci build and jprt tests.
Yes, please coordinate with Frank and Eric so that all of the jaxp
tests share the same configuration.
Post by Tristan Yan
For the tests which can not be run in secure mode(like tests for
xsltc direct extension), we'd add testng group called
?secure-hostile?. We won?t run these tests in secure mode by
bypassing them in secure run target. By this way we could easily
transform our tests as usual without additional effort.
I had been previously updated them so that all of the tests were
capable of running with and without security manager. Sustaining
SQE had invested several month to incorporate the changes into that
hosted in Aurora. Please consider taking the patches from them if
you haven't already done so.
Thanks,
Joe
Post by Tristan Yan
Thank you
Tristan
On Aug 19, 2014, at 10:32 AM, huizhe wang <huizhe.wang at oracle.com
By the way, the plan has been that all of the JAXP SQE and Unit
tests be migrated into [openjdk]/jaxp repo under jaxp/test. Tests
currently in the jdk repo shall be moved to jaxp/test as well. I
see that your webrev was generated in jdk9/dev/jdk. I hope it
doesn't mean you're checking tests into the jdk repo.
Thanks,
Joe
Post by Tristan Yan
Thanks Joe
We intend to replace the base class with test library because
that doesn?t look like a real base class but an utilities class.
I haven?t tried to run these tests with security manager, I will
run them with security manager then get back you soon.
Thank you.
Tristan
On Aug 18, 2014, at 4:32 PM, huizhe wang
Joe Darcy
2014-10-15 19:06:53 UTC
Permalink
Post by huizhe wang
Post by Eric Wang
Hi Joe,
Before performing the full investigation, I'm now leaning toward have
a "base" repo which would host files currently in the jdk, langtools,
and hotspot repos and then another repo for all the other library
code (jaxp, jaxws, corba).
Something like this?
otherlib repo/
jaxp/src and etc.
jaxws
corba
Currently, we are enjoying the benefit of being a repo by itself, that
is, using the whole repo as our workspace.
But I understand the need for consolidating, as long as it's in its
own root directory, I think it would be fine.
I'd expect something more like

otherlib repo/

src/$MODULE_NAME_FOR_JAXP
src/$MODULE_NAME_FOR_JAXWS
...

as now in the jdk repo, which may end up being basically isomorphic to
the above.

Thanks,

-Joe
huizhe wang
2014-10-15 20:04:02 UTC
Permalink
Post by Joe Darcy
Post by huizhe wang
Post by Eric Wang
Hi Joe,
Before performing the full investigation, I'm now leaning toward
have a "base" repo which would host files currently in the jdk,
langtools, and hotspot repos and then another repo for all the other
library code (jaxp, jaxws, corba).
Something like this?
otherlib repo/
jaxp/src and etc.
jaxws
corba
Currently, we are enjoying the benefit of being a repo by itself,
that is, using the whole repo as our workspace.
But I understand the need for consolidating, as long as it's in its
own root directory, I think it would be fine.
I'd expect something more like
otherlib repo/
src/$MODULE_NAME_FOR_JAXP
src/$MODULE_NAME_FOR_JAXWS
...
as now in the jdk repo, which may end up being basically isomorphic to
the above.
Make sense. JAXP is in one module anyways -- a positive for me :-)

Where would you think the tests would end up? otherlib repo/test?
otherlib repo/test
jaxp
jaxws
...

in which case, jaxp/test would be moved to otherlib repo/test/jaxp.

Thanks,
Joe
Post by Joe Darcy
Thanks,
-Joe
Tristan Yan
2014-08-29 16:50:28 UTC
Permalink
Hi Joe, Alan and others
I took over Eric?s last work and did some refactor for his code. Please help to review the code change again.
webrev: http://cr.openjdk.java.net/~tyan/JDK-8051561/webrev.01/ <http://cr.openjdk.java.net/~tyan/JDK-8051561/webrev.01/>
bug: https://bugs.openjdk.java.net/browse/JDK-8051561

These code has been run with security manager and without security manager both and all passed.
Thank you
Tristan
Post by Eric Wang
Hi Joe, alan and every one
I'm working on jaxp functional test colocation which is traced by the bug JDK-8043091 <https://bugs.openjdk.java.net/browse/JDK-8043091>.
We have finished to convert a few suite and the jaxp/xpath tracked by bug JDK-8051561 <https://bugs.openjdk.java.net/browse/JDK-8051561> is the first one chosen for public review.
Can you please review the webrev below? your comments given would be helpful for our future work.
http://cr.openjdk.java.net/~ewang/JDK-8051561/webrev.00/ <http://cr.openjdk.java.net/~ewang/JDK-8051561/webrev.00/>
Thanks,
Eric
huizhe wang
2014-08-29 18:21:24 UTC
Permalink
Hi Tristan,

Looks good. I left notes in the bug's comment section as a record and
status of the original test development.

Thanks,
Joe
Post by Tristan Yan
Hi Joe, Alan and others
I took over Eric?s last work and did some refactor for his code.
Please help to review the code change again.
webrev: _http://cr.openjdk.java.net/~tyan/JDK-8051561/webrev.01/
<http://cr.openjdk.java.net/%7Etyan/JDK-8051561/webrev.01/>_
bug: https://bugs.openjdk.java.net/browse/JDK-8051561
These code has been run with security manager and without security
manager both and all passed.
Thank you
Tristan
On Jul 25, 2014, at 6:12 AM, Eric Wang <yiming.wang at oracle.com
Hi Joe, alan and every one
I'm working on jaxp functional test colocation which is traced by the
bug JDK-8043091 <https://bugs.openjdk.java.net/browse/JDK-8043091>.
We have finished to convert a few suite and the jaxp/xpath tracked by
bug JDK-8051561 <https://bugs.openjdk.java.net/browse/JDK-8051561> is
the first one chosen for public review.
Can you please review the webrev below? your comments given would be
helpful for our future work.
http://cr.openjdk.java.net/~ewang/JDK-8051561/webrev.00/
Thanks,
Eric
Tristan Yan
2014-10-14 21:57:27 UTC
Permalink
Hi Joe
If you?re okay with the code; would you be my sponsor for this. We need move forward and push these tests into openjdk repo.
Thank you so much
Tristan
Post by huizhe wang
Hi Tristan,
Looks good. I left notes in the bug's comment section as a record and status of the original test development.
Thanks,
Joe
Post by Tristan Yan
Hi Joe, Alan and others
I took over Eric?s last work and did some refactor for his code. Please help to review the code change again.
webrev: http://cr.openjdk.java.net/~tyan/JDK-8051561/webrev.01/ <http://cr.openjdk.java.net/%7Etyan/JDK-8051561/webrev.01/>
bug: https://bugs.openjdk.java.net/browse/JDK-8051561 <https://bugs.openjdk.java.net/browse/JDK-8051561>
These code has been run with security manager and without security manager both and all passed.
Thank you
Tristan
Post by Eric Wang
Hi Joe, alan and every one
I'm working on jaxp functional test colocation which is traced by the bug JDK-8043091 <https://bugs.openjdk.java.net/browse/JDK-8043091>.
We have finished to convert a few suite and the jaxp/xpath tracked by bug JDK-8051561 <https://bugs.openjdk.java.net/browse/JDK-8051561> is the first one chosen for public review.
Can you please review the webrev below? your comments given would be helpful for our future work.
http://cr.openjdk.java.net/~ewang/JDK-8051561/webrev.00/ <http://cr.openjdk.java.net/%7Eewang/JDK-8051561/webrev.00/>
Thanks,
Eric
Loading...