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

Use Okhttp for jsoup connect and move jsoup class in to crawler #705

Merged
merged 8 commits into from
Mar 28, 2021

Conversation

codingPF
Copy link
Member

@codingPF codingPF commented Mar 9, 2021

Die Okttp Änderung ist in der JsoupConnection Klasse passiert.
Die Connection ist in den Crawler gewandert und wird dort mit den SenderConfig initializiert.
Testfälle sind angepasst.

@derreisende77
Copy link
Contributor

My 2ct:

  • JsoupConnection.getDocument() sollte statt response.code() IMHO besser response.isSuccessful() verwenden.
  • response.body() kann gem. Doku (und praktischer Erfahrung) null sein obwohl response successful: This always returns null on responses returned from cacheResponse, networkResponse, and priorResponse.
  • Daher sollte ein body != nullcheck eingefügt werden. Das Problem hatten wir an diversen anderen Stellen schon.
  • Ggf. wäre try-with-resources für ResponseBody dann auch nicht das schlechteste um Leaks zu vermeiden.
  • statt OkHttpClient.Builder() sollte MLib´s MVHttpClient genutzt werden damit alle denselben Timeout und User-Agent verwenden. Hat auch den Vorteil dass man dann sehr einfach traffic counter und traffic logging einbauen kann wie es im client schon vorhanden ist.

@pidoubleyou
Copy link
Contributor

der MVHttpClient wird in den neuen Crawlern bisher nicht verwendet, deshalb wird durch den Einbau an dieser Stelle nichts gewonnen. Zumal OkHttp durch dem Umbau weiterhin nur für das Lesen von HTML-Seiten verwendet wird, beiREST-APIs wird
WebTarget verwendet

@codingPF
Copy link
Member Author

Die Punkte 1 bis 4 habe ich hinzugefügt.
In MVHttpClient gibt es keinen User Agent und es wird nur das gleiche Timeout für alle crawler (static) gesetzt. Im Moment (und vorher) wurde das Senderkonfig Timeout verwendet. Das macht für mich erstmal mehr Sinn.

Copy link
Member

@Nicklas2751 Nicklas2751 left a comment

Choose a reason for hiding this comment

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

Sieht schon ganz gut aus. Ein paar kleinigkeiten habe ich noch gefunden. Ansonsten passt es für mich.

httpResponseCode = response.code();
if (response.isSuccessful()) {
if (response.body() != null) {
responseString = response.body().string();
Copy link
Member

Choose a reason for hiding this comment

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

Der responseString kann direkt return werden.

Copy link
Member Author

Choose a reason for hiding this comment

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

OK

if (response.body() != null) {
responseString = response.body().string();
}
break;
Copy link
Member

Choose a reason for hiding this comment

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

Anstatt der beiden breaks lieber einen if(response.body() == null || httpRepsonseCode == 404 || httpResponseCode == 410) und darin den reponse string auf leer setzen. Im else fall den reponse string auf den body setzen wie in Zeile 46. Nach dem if den response string returnen. So werden die beiden breaks eingespart und die Komplexität gesenkt.

Copy link
Member Author

Choose a reason for hiding this comment

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

OK

int retry = 0;
int httpResponseCode = 0;
String responseString = "";
while (retry < 3) {
Copy link
Member

Choose a reason for hiding this comment

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

Ich denke, eine do-while wäre hier verständlicher.

Copy link
Member Author

Choose a reason for hiding this comment

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

OK

}

public Document getDocument(String url) throws IOException {
return getConnection(url).get();
public String getString(String url) throws IOException {
Copy link
Member

Choose a reason for hiding this comment

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

getString ist recht nichts sagend, vorallem wenn man es dann im Crawler liest: crawler.getConnection().getString(

Zusätzlich verwirrt das get. Man könnte denken es wird nur eine variable ausgelesen und nicht eine Verbindung aufgebaut. Wie wäre es mit requestBody oder readUrlContent?

Copy link
Member Author

Choose a reason for hiding this comment

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

rename von getXYZ auf requestBodyAsXYZ

@pidoubleyou
Copy link
Contributor

@codingPF Der Build für den PR scheitert mit einem Compile-Fehler. Kannst du dir diesen anschauen?

final ResponseBody body = response.body()) {
httpResponseCode = response.code();
if (response.isSuccessful()) {
if (response.body() != null) {
Copy link
Member

Choose a reason for hiding this comment

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

Die beiden ifs könnte man noch zu einem vereinen. ;)

@Nicklas2751 Nicklas2751 merged commit aeba5e3 into mediathekview:develop Mar 28, 2021
@pidoubleyou pidoubleyou mentioned this pull request Mar 28, 2021
3 tasks
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.

4 participants