This allows configuration to work properly from the nomulus tool.
TESTED=I built and ran it against several environments, and all worked
properly.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146697124
There are still some options in RegistryConfig that can't be configured
in YAML, but it's not clear why anyone would need to change them from
their default values.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146482435
This is a temporary work-around that fixes the tool for all of our
environments. Next up I'm working on a generalizable way to get this
working by adding some kind of configuration between environment name
and App Engine project ID. The current configuration system doesn't
quite work for that because it's all based on a separate config per
environment, whereas the tool needs to be able to access all
environments. Either we bundle all configs that currently go into
WEB-INF/ with nomulus and have it select based on the -e flag, or we
make it a separate configuration.
TESTED=I built and ran locally and was able to successfully run
commands against alpha, production, and sandbox.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=146481850
Downstream users who use gRPC rather than REST don't want to pull down
rest-related dependencies.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145834701
This implements the basic framework that allows global YAML
configuration, per-environment custom configuration, and unit-
test-specific configuration.
TESTED=I deployed to alpha, ran some EPP commands through the
nomulus tool, and verified no errors.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145422680
This implements the basic framework that allows global YAML
configuration, per-environment custom configuration, and unit-
test-specific configuration.
TESTED=I deployed to alpha, ran some EPP commands through the
nomulus tool, and verified no errors.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=145422680
Also more narrowly scopes a catch block in TmchCertificateAuthority.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144744847
This allows us to use util methods from within config, which is a useful thing
to be able to do for, e.g., being able to log errors while loading configuration.
It makes sense that the util package should be at the very base of the
class inheritance hierarchy; config seems logically higher than it.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=144324273
This is the final preparatory step necessary in order to load and load
configuration from YAML in a static context and then provide it either via
Dagger (using ConfigModule) or through RegistryConfig's existing static
functions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143819983
We are now ready to begin configuration using YAML, mediated by ConfigModule.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143818507
The next step will be to get rid of RegistryConfig descendants and RegistryConfigLoader entirely.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143812815
This primarily addresses issues with TMCH testing mode and email sending utils.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=143710550
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
Nothing in the Nomulus release was using it and it's of questionable utility at
best. Nomulus isn't likely to be renamed at this point anyway.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=141301871
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
This changes everything with external visibility beyond the codebase
(i.e. the name of the compiled binary and the documentation that refers
to it). It does not change a lot of things internal to the codebase,
i.e. the "RegistryTool" class didn't change its name. We can rename that
in a subsequent CL if we want to.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135022087
TESTED=I deployed it on alpha, renamed some hosts, and verified that
the [] ran as expected.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134991941
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 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/RegistryConfig.java (Browse further)
