When a NodeAction was queried for which nodes were applicable, it
filtered out nodes that didn't have a nodeObject.
However, when a NodeRequest is similarly queried, null nodeObjects
were not filtered out and I guess it was up to the NodeRequest to
say "no" to null nodeObjects. This is not part of the API specification
for NodeApplicant, and in Spiral Knights we have various requests/actions
that simply return true without regard to the contents of the nodeObject.
So that's fucking retarded. Do the null check just like it's done
for NodeActions. In addition, do an extra check if one of single-node
methods is called for an action or request, to make sure that one
pre-determined node has a nodeObject set up. If not, log a warning,
and return an error response in the NodeRequest case.
This is to support running in ad-hoc, single-node noded mode.
However, it appears some code in here will choke on a null
node name.
This is for something in Spiral Knights, where we used to run
in non-noded or noded mode, and so we already cope with the
nodeName being null. Now we want to always run noded, so that
we can DRY and not check various local variables before checking
the (other) NodeObjects: now we can just check against all
the node objects.
So I may need to return here and make safe various equality
checks against the nodeName.
There is really no reason to maintain a .iml file in the repository anymore. This project can be loaded directly from POM files without trouble. I propose deleting this file.
This closes a giant security hole, but may break existing code.
PlaceObject.ManagerCaller is a poor-man's InvocationService, allowing
one to easily make a call to a method on the PlaceManager. The problem
is that this is turned on by default and any matching method is run.
This change disables it by default, but you may re-enable it by
overriding PlaceManager.handleManagerCalls() and returning true.
I also went ahead and made the ManagerCaller.invoke() method deprecated
so that you'll see a nice warning during compile time. You should
really consider just using a standard InvocationService to communicate with
the server. That way you effectively create a whitelist of client-callable
methods and there will be no surprises.
This is much simpler than requiring customizers to extend and override a bunch
of classes just to poke their fingers into the un/serialization process.
Premature optimization the fun side effect of rendering the
exception's attached stack trace completely useless.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6794 542714f4-19e9-0310-aa3c-eee0fc999fb1
It just leaves dependencies external by default when compiling an SWC, like any
sensible person would.
Also disabled warnings, since we never enabled them in the Ant build and
they're a giant list of spamming "hey, this class doesn't define a constructor"
warnings. Since when was it dangerous to rely on the default constructor?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6787 542714f4-19e9-0310-aa3c-eee0fc999fb1
The AS tests are still not compiled and run, but now at least they have a nice
place to live, in case someone ever wants to resurrect them.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6784 542714f4-19e9-0310-aa3c-eee0fc999fb1
The ActionScript code is now under aslib and is built via Maven (and Ant). The
CPP code is under cpplib and is ignored by everything (other than service
generation), but now at least it's not crufting up the Java submodule with its
XCode project.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6783 542714f4-19e9-0310-aa3c-eee0fc999fb1
This will allow us to properly ship narya-tools.jar to Maven Central which is
necessary for Nenya and Vilya (and any other Narya-using project) to themselves
be built.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6776 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray J. Greenwell