We need to set up the preference interval (but not start it) before we try to open the connection. Otherwise, we won't have it around if we get a shutdown call during that opening (which can and does happen).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4274 542714f4-19e9-0310-aa3c-eee0fc999fb1
where we don't think it ever will.
Instead of returning null, or the exception, always throw a runtime
with just the CloneNotSupportedException as the argument, as this will
contain the most information and will preserve the stack trace.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4264 542714f4-19e9-0310-aa3c-eee0fc999fb1
I was getting an IllegalArgumentException and the message was "null",
so this will at least log the name of the exception.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4263 542714f4-19e9-0310-aa3c-eee0fc999fb1
forEach(), in which you pass a visitor function that will visit each key/value
stored in the map.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4257 542714f4-19e9-0310-aa3c-eee0fc999fb1
inner bits are all clear and ready to try logging on to a new server. We
specifically wait to call clientLogonFailed() until after everything is
cleared, but I don't want to change the behavior of clientDidLogoff() for fear
that any one of the zillion directors depends on something being around during
that call.
Instead I added another callback clientDidClear() that is called when a
successful session is fulled cleared out (basically when we're not calling
clientLogonFailed()) so that entities that are waiting for a logoff to finish
so that they can logon somewhere else have a clean way of doing so.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4255 542714f4-19e9-0310-aa3c-eee0fc999fb1
like to change the ordering for ChatMessage and its other derivations (the
bundle should precede the message) but that's more dangerous as the constructor
signature would not change.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4253 542714f4-19e9-0310-aa3c-eee0fc999fb1
- the ChatProvider is now a proper singleton rather than providing static
methods for everything (it is accessed through CrowdServer.chatprov)
- it can now be extended to create a custom UserMessage for tells (which can
contain avatar information on systems that want to show an avatar on the
receipt of a tell)
- the ChatProvider API was tidied up a bit as some methods had been addded over
time that were not sufficiently general purpose so their callers will be
changed to use the general purpose APIs.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4251 542714f4-19e9-0310-aa3c-eee0fc999fb1
we can't rely on building a new client info at session end time because the
client's ClientObject will have been destroyed.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4250 542714f4-19e9-0310-aa3c-eee0fc999fb1
decrement the reference count of the client object as it is normally
incremented for every resolution listener.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4248 542714f4-19e9-0310-aa3c-eee0fc999fb1
required some serious bending and folding of the generic type system, but for
the most part we managed to avoid any mutilating. The gendobj task now
generates properly typed "addToXXX" and "updateXXX" DSet methods based on the
parameterized type of the DSet. This might cause unrecompiled code to break,
but I don't think there are many cases in the base toolkit where people call
DSet adders or updaters. We'll see and I'll add backwards compatibility
versions for cases where we need them to support GG games (everything else we
can just recompile).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4245 542714f4-19e9-0310-aa3c-eee0fc999fb1
construct that could be made to do what I want in a type safe manner. The
method returns Class<? extends NodeObject> which is correctly expresses the
valid types that can be returned.
However, I can't pass the capture <? extends NodeObject> (NodeObject extends
DObject) to a method that takes <T extends DObject>. I'm not entirely sure why
not, but I imagine it has something to do with the subtleties of type-erasure,
or maybe it's just a limitation of the inference that can be done by the
compiler. I don't know what type <? extends NodeObject> is considered to be, I
would have thought just NodeObject but apparently not.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4242 542714f4-19e9-0310-aa3c-eee0fc999fb1
resolution fails for whatever reason and we will properly track our pending
resolutions (not leaving them dangling if resolution failed) and do so more
elegantly (by simply acting as a ClientResolutionObserver ourselves).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4239 542714f4-19e9-0310-aa3c-eee0fc999fb1
make connections to other servers in the cluster and can exchange events (in a
limited fashion).
This is different than Liz's project wherein servers share an oid space and one
can interchangably work with distributed objects from any server. This package
provides a means by which certain services (by default, presence and chat) can
be communicated between servers to allow communication between players
scattered around a bunch of otherwise independent server instances.
This is less general purpose but also less likely to encourage people to write
code that tightly couples multiple servers and then falls over because it
generates gobs of network traffic as events are flung willy nilly behind the
scenes.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4238 542714f4-19e9-0310-aa3c-eee0fc999fb1
asynchronous exception, so we can't use it or badness will ensue.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4235 542714f4-19e9-0310-aa3c-eee0fc999fb1
- Import bleeding may be fixed, as I had to import a bunch of things I
should have had to earlier.
- NOW they make duplicate variable definitions bad (but without block
scoping... yay).
- Another hoopjump.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4233 542714f4-19e9-0310-aa3c-eee0fc999fb1
code but new code should use the new logging style:
import static com.threerings.presents.Log.log;
and call log.info(), log.warning(), etc. We can migrate old code as the desire
grips us.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4231 542714f4-19e9-0310-aa3c-eee0fc999fb1
inheriting a socket channel inetd style. It doesn't actually work for annoying
reasons, but I figured I'd get the code in there and the type safety fixes and
maybe Sun will fix their stupid bug at some point (I should create a test case
and actually submit a bug report...).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4230 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray Greenwell