pages which give us something useful to link to when we want to point to all of
the javadocs for a particular subtree of the Narya packages.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5411 542714f4-19e9-0310-aa3c-eee0fc999fb1
thing before committing instead of just going "oh yeah, I've been having this stuff
sitting around uncommitted for a while waiting on it to be blessed" and missing
out on things that'd changed in the meantime.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5400 542714f4-19e9-0310-aa3c-eee0fc999fb1
Note: this involves generated code from a samskivert patch I only just sent to mdb,
but he's in a meeting, so that won't show up for a little.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5369 542714f4-19e9-0310-aa3c-eee0fc999fb1
importing receivers from their senders to satisfy their links.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5333 542714f4-19e9-0310-aa3c-eee0fc999fb1
directly to stderr. Logging an exception with the associated warning does the
right thing and logs the stack trace via the logging system.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5318 542714f4-19e9-0310-aa3c-eee0fc999fb1
a singleton. At any rate, it fixes Project X, which we're
supposed to demo soon.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5317 542714f4-19e9-0310-aa3c-eee0fc999fb1
channel distributed objects but rather resolves the location of all channel
participants on every message delivery so that we don't have to attempt the
very fragile process of having every server that hosts a channel participant
maintain a subscription to the chat channel object on another peer.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5305 542714f4-19e9-0310-aa3c-eee0fc999fb1
was necessary (javac claimed it was, Eclipse claimed it wasnt'). Fortunately,
we can do everything with Class<FooClient> methods that avoid the need for
supression entirely.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5275 542714f4-19e9-0310-aa3c-eee0fc999fb1
How was this not a problem before? Maybe we just got lucky
on yohoho and never had an npp say something with filterable
words in the translation key.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5237 542714f4-19e9-0310-aa3c-eee0fc999fb1
to delegates that can handle them. Turns out we already even had this option in
the PlaceController.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5224 542714f4-19e9-0310-aa3c-eee0fc999fb1
beginning of words in those times when 2 bytes just aren't enough for a letter.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5219 542714f4-19e9-0310-aa3c-eee0fc999fb1
extending systems and depended upon by services that need to lookup bodies.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5212 542714f4-19e9-0310-aa3c-eee0fc999fb1
Place manager delegates now store their own references to the omgr and invmgr
and set the members via the init function. This is fine, but due to the order
of calling PlaceManager's init and addDelegate, the PlaceManagerDelegate.init
was receiving null values.
The fix is to provied a more consistent guarantee about the relationship
between init and addDelegate. After both have been called (regardless of
order), we guarantee that both init and didInit have been called on all
delegates.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5177 542714f4-19e9-0310-aa3c-eee0fc999fb1
bind something to PeerManager.class will result in initialization failure.
A system that uses the peer services needs to extend PeerManager or
CrowdPeerManager with a concrete PeerManager and then
bind(PeerManager.class).to(SomePeerManager.class) to properly satisfy the
dependency.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5171 542714f4-19e9-0310-aa3c-eee0fc999fb1
dependencies into both. Moved the legacy statics into CrowdServer so that at
least Presents can be pure (we should probably eventually move them into
BangServer and PiracyServer and fix everything else). Added some useful manager
references to PlaceManager delegate (_omgr, _invmgr) that handle the majority
of their service needs.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5170 542714f4-19e9-0310-aa3c-eee0fc999fb1
LocationProvider can be an interface like its brothers and sisters.
Modified the place registry to create PlaceManager instances using the injector
so that we can inject dependencies into managers. Also modified the custom
classloader functionality so that it can/will circumvent this process
entirely. It's not possible to inject using a custom classloader and one
certainly would not want to do so.
Unfortunately this means we can't inject some basic managers into PlaceManager
because it needs to work for games loaded into a sandboxed classloader, but the
big win is that in everything other than GameManager and PlaceManager, we can
inject to our heart's content.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5168 542714f4-19e9-0310-aa3c-eee0fc999fb1
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
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
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
Michael Bayne