Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(#42) HtHead can be broken. #69

Merged
merged 1 commit into from Feb 23, 2019
Merged

Conversation

ilyakharlamov
Copy link
Contributor

( #42 ) HtHead can be broken

  • Adds unit test for buffer tearing
  • Replaces the double loop with a scanner

@0crat 0crat added the scope label Jan 15, 2019
@0crat
Copy link
Collaborator

0crat commented Jan 15, 2019

Job #69 is now in scope, role is REV

@0crat
Copy link
Collaborator

0crat commented Jan 15, 2019

This pull request #69 is assigned to @victornoel/z, here is why; the budget is 15 minutes, see §4; please, read §27 and when you decide to accept the changes, inform @llorllale/z (the architect) right in this ticket; if you decide that this PR should not be accepted ever, also inform the architect; this blog post will help you understand what is expected from a code reviewer; there will be no monetary reward for this job

@codecov-io
Copy link

codecov-io commented Jan 15, 2019

Codecov Report

Merging #69 into master will decrease coverage by 0.39%.
The diff coverage is 100%.

Impacted file tree graph

@@             Coverage Diff             @@
##             master      #69     +/-   ##
===========================================
- Coverage      96.9%   96.51%   -0.4%     
+ Complexity       67       61      -6     
===========================================
  Files            17       17             
  Lines           194      172     -22     
  Branches         15        9      -6     
===========================================
- Hits            188      166     -22     
  Misses            4        4             
  Partials          2        2
Impacted Files Coverage Δ Complexity Δ
src/main/java/org/cactoos/http/HtHead.java 100% <100%> (ø) 3 <2> (-6) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9f10348...89c7a77. Read the comment docs.

Copy link
Contributor

@victornoel victornoel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ilyakharlamov see my comments :) it's a nice solution!

*/
private static final int LENGTH = 16384;
private static final String DELIMITER = "\r\n";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ilyakharlamov it would be more elegant if the constructor took this information instead of making it fixed like this. There should be a secondary constructor that set it to \r\n then.

This is more of an architectural choice so @llorllale should confirm first I think :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ilyakharlamov @llorllale let's forget about this, the delimiter is strongly related to the behaviour of this class, no need to introduce an extra parameter

src/main/java/org/cactoos/http/HtHead.java Show resolved Hide resolved
Matchers.allOf(
Matchers.startsWith("HTTP"),
Matchers.containsString("OK\r\nReferer"),
Matchers.endsWith("text/plain")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ilyakharlamov please use the OO version of the matchers (instantiate them with new XXX intead of the static method), and if possible use those available from cactoos-matchers

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would be the replacement for Matchers.allOf ?
I guess that supposed to be
new AllOf<>( new IterableOf<>( new StringStartsWith("HTTP"), new StringContains("OK\r\nReferer"), new StringEndsWith("text/plain") ) )
However that throws a compilation warning "unchecked generic array creation for varargs".
Please advise what to replace static Matchers.allOf with.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ilyakharlamov you are right, it is too much with new AllOf, let' keep the static only for allOf then and see if @llorllale is good with it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ilyakharlamov also use cactoos-matchers StartsWith, TextHasString and EndsWith

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@victornoel As far as I understand StartsWith, TextHasString and EndsWith are coming in cactoos-matchers 0.13 which has not been released yet, so it's not available in maven, so can't use it yet.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

);
MatcherAssert.assertThat(
block.length(),
new IsEqual<>(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ilyakharlamov please use cactoos-matchers' TextIs

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here I am constructing a block and making sure it has the exact length of the block.
How TextIs can help to verify that the string is of a certain size?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ilyakharlamov you are right yes. I think this test is too complex to be easily understandable.

Why are you checking the block length? You are not testing HtHead here, so I don't think you should be asserting anything. I would advise to remove this assertion.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@victornoel In order to reproduce the issue, I need to have a header of the exact size of the block (16384 bytes)
So it's way too easy to miss one character, like one extra space and the block will be 16383 or 16385 and the test will yield a false-positive result. So here I am checking the length to make sure that the constructed header is exactly 16384 bytes before running the actual test.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ilyakharlamov ok, it's good for me then, thank you for the explanation

this.scanner.next()
);
if (this.hasMoreElements()) {
builder.append(HtHead.DELIMITER);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ilyakharlamov can you double check that we want to include the delimiter in the resulting InputStream? In the original code I see this line if (found) { tail = tail - end.length + 1; } which let me think it should not be included

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've checked against the previous commit 487af7 and
Matchers.containsString("OK\r\nReferer") passes .
Which makes sense. Since the goal is to separate the HTTP header from the body so the separator between the headers needs to be kept.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ilyakharlamov ok yes, i better understand, thank you for confirming :)

"",
"text here"
new TextOf(""),
new TextOf("body here")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ilyakharlamov in this case I wouldn't have bothered to use TextOf, it is a bit too much I think :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

new StringStartsWith("HTTP"),
new StringContains("OK\r\nReferer"),
new StringEndsWith("text/plain")
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ilyakharlamov when cactoos-matches is released, please use directly allOf with Text based matchers (instead of using TextIs which makes all of this akward :)

@@ -102,8 +110,54 @@ public void largeText() throws IOException {
)
)
).asString(),
Matchers.endsWith("text/plain")
new StringEndsWith("text/plain")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ilyakharlamov please replace this with cactoos-matchers EndsWith (and don't call asString() on the Text)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@victornoel Not sure I understand. I have a Text, and a EndsWith. EndsWith is basically a Matcher<String>. How do I assert them between each other without using asString()?
new Assertion<>("description", Text, Matcher<String>) is obviously not compilable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@victornoel thank you, I was very confused, there are so many matchers in the classpath with similar names that do similar things but incompatible. fixed in 8915ec4

@victornoel
Copy link
Contributor

@ilyakharlamov I've added a few comments, we are almost there :)

@victornoel
Copy link
Contributor

@ilyakharlamov thank you for your patience, I think it's all good now :)
@llorllale this is good to merge!

@llorllale
Copy link
Collaborator

llorllale commented Jan 22, 2019

@ilyakharlamov I cringed when I saw Enumeration. Is there any way we can get creative and replace enumeration with some composition of org.cactoos.io.Joined and others? It could potentially allow us not to define a class just for this.

@ilyakharlamov
Copy link
Contributor Author

@llorllale That can be possible after cactoos#1035.

@victornoel
Copy link
Contributor

victornoel commented Jan 28, 2019

@ilyakharlamov apparenty yegor256/cactoos#1038 that solves yegor256/cactoos#1035 has been merged a few days ago, I suppose you can continue the work here?

@ilyakharlamov
Copy link
Contributor Author

@victornoel Even though the yegor256/cactoos#1038 is merged, it is not released (will be cactoos 0.39). I am not responsible for cactoos-releases, it may be a few month before we have 0.39.

@victornoel
Copy link
Contributor

@ilyakharlamov you should ask ARC in the issue you are interested in to make a new release

@victornoel
Copy link
Contributor

@ilyakharlamov cactoos 0.39 has been released (see yegor256/cactoos#1035)

@ilyakharlamov
Copy link
Contributor Author

@0crat wait #72

@victornoel
Copy link
Contributor

@ilyakharlamov it has already been released... and also it is useless to tell 0crat to wait in a PR

@victornoel
Copy link
Contributor

@ilyakharlamov just update the dependency and fix the PR

@0crat
Copy link
Collaborator

0crat commented Feb 2, 2019

@0crat wait #72 (here)

@ilyakharlamov It's a code review job #69, can't put it on hold

@ilyakharlamov
Copy link
Contributor Author

ilyakharlamov commented Feb 2, 2019

@victornoel Cactoos 0.39 introduces a few signature changes.
For some reason it decided to use checked exceptions everywhere (I thought checked exceptions are dead), so it's not a minor change, it will affect dozens of files just to upgrade, so will wait for #72.

@victornoel
Copy link
Contributor

@ilyakharlamov yes, you are right, thanks for the explanation

@victornoel
Copy link
Contributor

@ilyakharlamov cactoos-http now uses cactoos 0.39, I believe we can continue here now :)

@victornoel
Copy link
Contributor

@ilyakharlamov thanks for your patience, it looks real nice now :)
@llorllale good to merge

@llorllale
Copy link
Collaborator

@victornoel @ilyakharlamov I just want to mention that @dgroup's hamcrest PR to add AllOf vararg ctor got merged a while back, so we should remove Matchers.allOf after their next release.

@llorllale
Copy link
Collaborator

@rultor merge

@rultor
Copy link
Collaborator

rultor commented Feb 23, 2019

@rultor merge

@llorllale OK, I'll try to merge now. You can check the progress of the merge here

@rultor rultor merged commit 89c7a77 into yegor256:master Feb 23, 2019
@rultor
Copy link
Collaborator

rultor commented Feb 23, 2019

@rultor merge

@llorllale Done! FYI, the full log is here (took me 12min)

@0crat
Copy link
Collaborator

0crat commented Feb 23, 2019

Code review was too long (39 days), architects (@llorllale) were penalized, see §55

@0crat 0crat removed the scope label Feb 23, 2019
@0crat
Copy link
Collaborator

0crat commented Feb 23, 2019

The job #69 is now out of scope

@0crat
Copy link
Collaborator

0crat commented Feb 23, 2019

Order was finished: +15 point(s) just awarded to @victornoel/z

@0crat
Copy link
Collaborator

0crat commented Feb 23, 2019

Payment to ARC for a closed pull request, as in §28: +10 point(s) just awarded to @llorllale/z

@ilyakharlamov ilyakharlamov deleted the block-tearing branch February 24, 2019 05:58
@llorllale llorllale mentioned this pull request Jun 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants