I'm setting it to three buckets across all tests, because the default one bucket
wasn't realistic enough, and allowed some tests to pass that shouldn't have,
essentially by accident.
This also changes RegistryConfig from being an interface to being an abstract
base class. The medium term goal here is to have it be a static class so that it
can provide fields from the YAML-derived POJO in situations where Dagger
injection isn't feasible.
The expected end state is as follows:
default-config.yaml -- The master config file that provides defaults for all
values.
nomulus-config.yaml -- A per-environment config file that overrides the defaults
from the previous file.
YamlConfig.java -- The POJO that the aforementioned YAML files are deserialized
into.
RegistryConfig.java -- Contains a static, memoized instance of YamlConfig and
provides static methods for getting some of those values.
ConfigModule -- Will become a static inner class of RegistryConfig, using Dagger
to provide most of the fields from the memoized YamlConfig instance. This way,
all configuration will be coming from a single place: RegistryConfig.java.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143567288
This is the first in a decently long series of commits to delete RegistryConfig
entirely and centralize all configuration in ConfigModule using Dagger. Once
this is done, then the text-based YAML configuration work can begin in earnest.
Note that the configuration settings from TestRegistryConfig will be moving
into ConfigModule.LocalTestConfig. This way they can be referred to in a static
context from test and test utility helpers, rather than having to be injected
everywhere, which we don't typically bother with for tests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143473089
To add additional logic for flow code, write custom classes that extend the existing custom logic classes (of which DomainCreateFlowCustomLogic is the first provided example), along with a class that extends CustomLogicFactory to provide instances of the new custom logic classes. Then configure the fully qualified class name of your new custom logic factory in ConfigModule.provideCustomLogicFactoryClass().
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=139221577
Convert to an action and remove ResourceServlet, JsonTransportServlet and
JsonTransportServlet, all of which exist only to support it.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137519385
Replace the two drive links on the "contact us" page with values that can be
driven from the config. The drive links are the link to the technical
documentation folder and the link to the registrar's transaction activity
reports. The former is a straightforward static replacement, but the latter
is derived from a per-registrar Google Drive id which must be formatted using
a template from the config module.
Note: This currently requires adding the transaction activity URL template to
the old-style RegistryConfig class instead of the daggerized ConfigModule
because this is the easiest way to pass it though to the non-daggerized
RegistrarServlet. In an upcoming CL, I'll convert RegistrarServlet to
RegistrarAction and then I'll be able to make this template injectable.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137518466
Parameterize integration, support and announcement email addresses and contact
phone number, make static parameters flow through the system in a consistent
manner.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136183813
This allows handling of N asynchronous deletion requests simultaneously instead
of just 1. An accumulation pull queue is used for deletion requests, and the
async deletion [] is now fired off whenever that pull queue isn't empty,
and processes many tasks at once. This doesn't particularly take more time,
because the bulk of the cost of the async delete operation is simply iterating
over all DomainBases (which has to happen regardless of how many contacts and
hosts are being deleted).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133169336
This change refactors EppMetrics from the mutable self-exporting thing that it
was into a real value type EppMetric, and delegates exporting functionality to the
BigQueryMetricsEnqueuer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132387660
The instrumentation implementation adds the ability to track counters for dimensional data in the codebase. Instrumentation points will be added to different parts of the codebase in upcoming CLs. The ability to export the data to Stackdriver will also be added in an upcoming CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=130195199
According to Gustavo Lozano of ICANN: "In the case of the RDAP profile (gTLD space), the “port43” element is not expected to be used, because Whois/43 tcp will be deprecated in the future." So it sounds like we should not include the port43 element for the moment.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=130017966
This change allows registries to customize the values returned by
RegistryConfig methods without needing to edit Domain Registry code in a
forked repository. This is accomplished by defining a custom
RegistryConfig implementation and specifying its name as a system
property in appengine-web.xml.
This change also open-sources the production configuration values that
Google has chosen to use for these methods. TestRegistryConfig was
hitherto used for production configuration in the open source world,
which is misleading and inappropriate, considering it tunes values such
as the number of commit log buckets to 1.
Another important benefit of this change is that it helps registry_tool
work out of the box in the open source world.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=129022675
This fixes#23 for @parsoj by allowing a custom disclaimer to be
specified via dependency injection modules.
By making the disclaimer part of the dependency injection graph, it can
come from anywhere.
For example, if I was Donuts, I would have my own repository. I'd use an
external http_archive() repository for Domain Registry. Then I would
write my own Dagger @Component for each App Engine module. My Component
would have a list of Dagger Modules, which I copied from the Domain
Registry version. Then I would swap out ConfigModule with my own
DonutsConfigModule, which provides the same values.
So long as a method exists that @Provides @Config("whoisRegistry"), and
the module containing it is listed in the @Component, the dependency
injection graph becomes valid and complete for the whois package
(provided other dependencies are met.)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=128082921
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/config/ConfigModule.java (Browse further)
