More dependency injection (or removal in the case of SpeakUtil).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5163 542714f4-19e9-0310-aa3c-eee0fc999fb1
- Inject the auth Invoker.
- Inject the Authenticator and formalize the chaining authenticator pattern.
- Simplify PeerNode creation and make the PeerAuthenticator a chainer.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5162 542714f4-19e9-0310-aa3c-eee0fc999fb1
PresentsServer legacy shutdown stuff. We'll wire that up in the legacy servers
themselves.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5157 542714f4-19e9-0310-aa3c-eee0fc999fb1
subclasses provide PresentsServer "services" we'll just have no PresentsServer
services. All services will be provided by components and the server will
disappear in a puff of inversion of control.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5155 542714f4-19e9-0310-aa3c-eee0fc999fb1
is only ever used by the PresentsServer. Also determined that we need to
explicitly let Guice know that CrowdServer provides the PresentsServer
"interface" and so on down the line.
I also think that each concrete class needs to be marked as @Singleton though I
need to confirm that. Based on how annotations work, that's how it would be
easiest to implement, so we'll assume they're not doing extra work on the
backend to make our life easier.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5154 542714f4-19e9-0310-aa3c-eee0fc999fb1
dependency resolution and management. Things are currently in a state of
transition, but the important patterns have been established and I'll aim to
sweep through all of Narya, Nenya and Vilya in the near future and do
everything properly.
Going through the other million-odd lines of code we have scattered across our
various projects that use these libraries is not something I plan to do, so
we'll be maintaining backward compatibility with the old static member method,
though I hope to strive toward eradication of that usage entirely in MSOY while
we still have a fighting chance.
Given that some of our projects will continue to use the static member method
in perpetuity, I'm not going to @Deprecate those fields because that would fill
their logs with so much spam that they'd have to turn off deprecation warnings
which would make life worse for them. So instead we'll settle for the big scary
comment warning people away from the old bits.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5153 542714f4-19e9-0310-aa3c-eee0fc999fb1
* Token member for bureaus
* Exception type for failed authentication
* Authenticate function
* Bureau id to credentials
* Fixed bad constructor and toString
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5149 542714f4-19e9-0310-aa3c-eee0fc999fb1
add convenience wrappers giving us a boolean back instead of forcing us to see
if checkAccess(blah) == null.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5132 542714f4-19e9-0310-aa3c-eee0fc999fb1
to write everything in two languages, and now have to take special care that
things written in one of those languages works properly in a wholly separate
and somewhat limited deployment environment. Ah such sweet forgetting.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5119 542714f4-19e9-0310-aa3c-eee0fc999fb1
easily make use of different permission policies in different circumstances
(one can imagine a hypothetical partner who has different access control
requirements, perhaps).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5118 542714f4-19e9-0310-aa3c-eee0fc999fb1
allowing the use of annotations to customize transport for
DObject fields and service/receiver methods.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5099 542714f4-19e9-0310-aa3c-eee0fc999fb1
I just feel like: imagine if there were no Map.containsKey().
You would instead have to get() the value and see if it's not null.
If you did that, you certainly wouldn't throw away the value if you
were going to get it again right below, would you? So why would
you do it simply because of the addition of a convenient method
called containsKey()?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5067 542714f4-19e9-0310-aa3c-eee0fc999fb1
crowd was intentional (with presents on top because it is more "generic"). We
must resist Eclipse's desire to squish our imports together into one giant,
hard to (visually) parse blob.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5060 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne