This was inadvertently introduced in [] - the original code manually URL-encoded the XML, but the TaskOptions.param() method does that for you, so now we're double-URL-encoding the XML and as a result the actual /_dr/epptool invocation is failing with a syntax error (which was somewhat hard to diagnose, since it logs nothing and returns HTTP 200 in that case - to be fixed separately).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137321114
This adds XSRF tokens so that the epptool request succeeds, adds better logging for debugging load test requests, adds better validation, and improves documentation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136885117
It's best to be consistent and use the same thing everywhere. "clientId" was
already used in more places and is shorter and no more ambiguous, so it's the
logical one to win out.
Note that this CL is almost solely a big Eclipse-assisted refactoring. There are
two places that I did not change clientIdentifier -- the actual entity field on
Registrar (though I did change all getters and setters), and the name of a
column on the exported registrar spreadsheet. Both would require data
migrations.
Also fixes a few minor nits discovered in touched files, including an incorrect
test in OfyFilterTest.java and some superfluous uses of String.format() when
calling checkArgument().
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133956465
The load tests used to directly build EPP, but that becomes
problematic for an upcoming CL that refactors a lot of the
EPP flow code. Instead, use the existing tool endpoint
(conveniently, LoadTestAction is already in the tools module).
This required changing the EppToolServlet to get its
xml from a param rather than from the request payload,
since task queues won't allow both a payload and request
params on the same task.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=124351878
The dark lord Gosling designed the Java package naming system so that
ownership flows from the DNS system. Since we own the domain name
registry.google, it seems only appropriate that we should use
google.registry as our package name.
This change renames directories in preparation for the great package
rename. The repository is now in a broken state because the code
itself hasn't been updated. However this should ensure that git
correctly preserves history for each file.
2016-05-13 18:55:08 -04:00
Renamed from java/com/google/domain/registry/loadtest/LoadTestAction.java (Browse further)
