Hi Langer,

Thanks for the update. I'll do an all-test run. I'm okay with the TransformerTest, although it can be better. For the license header, I meant to say the whole header that includes updating the Apache License to its new format. You may update the webrev if you want. Otherwise, I can do so when I check in once all tests pass.

Thanks again,
Joe

On 3/8/2016 3:59 PM, Langer, Christoph wrote:
Hi Joe,

answers inline.

Thanks for reporting and providing patch for the issue!  Looks like a
nice solution that may potentially reduce memory requirement for some
large templates. Could you also verify that the patch also fixes
JDK-8150699 [1] that was created the same day as yours?
Yes, which coincidence. The issue basically is the same. I've picked the bug 
and marked it as duplicate

I assume the stylesheet is created to just illustrate the issue. If it's
a real use case, then it should have made the variable global to avoid
creating a lot of RTFs, and therefore avoid the whole "No more DTM IDs"
issue. It would make the process a lot more efficient.
Yes, it is an artificial transformation which should recreate the issue.

Some classes, such as Sort.java, still contain the old header, please
update them with the new ones such as that in DOM.java.
Did that.

The $Id section, such as the following, can all be removed, they were
from legacy repository, misleading since it implies the file was last
updated, in this case, in 2005:

    20 /*
    21  * $Id: Sort.java,v 1.2.4.1 2005/09/12 11:08:12 pvedula Exp $
    22  */
Did that as well.

For the new test, it's probably better to add some kind of assertion in
the test, e.g. expected result, than failing on a broad Exception. What
if the test passes but the transform operation isn't because of the changes?
I've modified that part, asserting that the result matches a reference.

The test is also not sufficient. The release methods seem to be okay.
However, they don't seem to have been fully exercised in the test (only
simple RTs were created?).  In that sense, the sample attached in
JDK-8150699 provided an opportunity to better verify the changes.
Yes, I had a hard time creating an artificial scenario which would reproduce 
the issue and would also stress all places. I was rather running into 
StackOverflows than out of DTM IDs. Eventually I managed to create something 
but obviously not comprehensive enough. I also had some customer data which I 
was eventually allowed to publish as testcase but the data was quite large and 
the xsl very complex so the transformation would run very long. I have now 
included the sample from JDK-8150699 into the test as well.

It would be good to add some javadoc or dev notes to the test. While
consolidating tests (into TransformerTest), please make sure
notes/javadoc are copied over or added.
I added a sentence of documentation for my testcase. For the consolidated ones 
I now copied what was there and added a dummy summary text for the tests where 
nothing was existing before.

This is the new webrev:
http://cr.openjdk.java.net/~clanger/webrevs/8150704.2/

I just ran the tests out of javax/xml/jaxp/unittest/transform. Maybe you will 
want to do some more testing before pushing, e.g. JCK.

Let me know if I should do some further adaptions.

Thanks
Christoph

Reply via email to