calls on the Java side, to match this added convenience we introduced to the
ActionScript side some time ago.
Before arms are raised into the air and waved like they really do care, bear
the following in mind:
Nothing will change at all on your project until you take some action to do so.
That action could include any of the following:
1. Continue to use narya-tools-1.2 to run genservice and you'll get the old
style "pass a Client reference for every service method invocation" marshallers
and you can continue to live happily in the past.
2. Leave some of your stuff un-regenerated, but generate new stuff using the
new tools and use the Client-reference-free style for new services. This is
likely to engender some PITA if you're trying to use both styles in the same
project because genservice just wants to operate on everything, but I offer it
as an option in case some other PITA motivates the tolerance of this
(presumably smaller) PITA.
3. Embrace the brave new world of simplicity and wield your good friend sed for
fun and profit:
(make necessary build.xml updates to start using narya-tools-1.4-SNAPSHOT)
% find src -name '*Service.java' | xargs sed -i 's:Client client, ::g'
(this will remove the Client argument from most of your services, some manual
fixes may be needed)
% ant genservice
% find src -name '*.java' | xargs sed -i 's:_ctx.getClient(), ::g'
(this will fix most of the places that pass a client reference into an
invocation service, some manual fixes will probably be needed)
I did this on Vilya and it magically took care of like 95% of the places where
changes were needed. The remaining half dozen changes were painless. Clearly
something like Yohoho vastly dwarfs Vilya in scope, but someone looking for an
hour or two of mindless typing to distract them on a lazy Sunday afternoon
would likely breeze through even that vast codebase without breaking a sweat.
Two more notes:
1. I'm going to switch Narya and Vilya over to the new style, and I'll be
fixing all the projects that use their services.
2. I lied (a teeny bit) about nothing changing. I made the old Client-taking
sendRequest methods deprecated, so projects that don't switch to the new style
will be presented with a large number of deprecation warnings. If this is too
terrible a burden to bear, I can remove the deprecation annotations on those
methods.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6395 542714f4-19e9-0310-aa3c-eee0fc999fb1
us to create a Scala trait that handles reading and writing Scala "fields"
which are not public fields but are rather private fields with public getters
and setters. This also enables the creation of bridges for other JVM-hosted
non-Java languages.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6391 542714f4-19e9-0310-aa3c-eee0fc999fb1
(Hope I'm not stepping on anyone's toes with this; I'm happy to revert if there are strong arguments against.)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6390 542714f4-19e9-0310-aa3c-eee0fc999fb1
(Eclipse's auto-import-ordering makes it too easy for manually-added imports to get moved to a location where they'd be blown away by the task.)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6388 542714f4-19e9-0310-aa3c-eee0fc999fb1
The easiest way to accomplish this, if you have a degree of control over your page, is with something like:
RootLayoutPanel.get().add(new ConfigEditorPanel(barHeight));
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6387 542714f4-19e9-0310-aa3c-eee0fc999fb1
duration a bit less far. And Ray will be pleased to know that we're doing much
less redundant arithmetic.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6385 542714f4-19e9-0310-aa3c-eee0fc999fb1
If a generated section like
// GENERATED BLAH START
var s: String = "I am some awesome stuff you didn't have to write";
// GENERATED BLAH END
is replaced with
// GENERATED BLAH DISABLED
that generated section will no longer be merged in.
This currently allows the class declaration to be customized in the actionscript
stuff, if it needs to extend or implement something that can't be inferred from
the Java class. If someone's feeling frisky, they could split the streamable
section into sections for readObject, writeObject and fields to allow for read
and write customization.
This also fixes dropping no-longer generated sections and allows for sections
to be reordered in the source.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6383 542714f4-19e9-0310-aa3c-eee0fc999fb1
expressions. We'll get to a new stable release soonish.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6379 542714f4-19e9-0310-aa3c-eee0fc999fb1
to suppress subscription failure events in addition to subscription success, as
well as event forwards (though those shouldn't, in theory, go out over a new
connection because subscribers are cleared when a connection is dropped).
Nothing else looked like it might result in a spurious message being sent if a
connection was dropped and reestablished, so none of the other calls were made
to supply an expected connection.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6376 542714f4-19e9-0310-aa3c-eee0fc999fb1
on one connection, then disconnects. While that request is in the
pipeline, it reconnects, then receives the subcription that the first
connection requested before it sends its own subscription requests. To
prevent this, make sure that the current connection is the same one
that made the request.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6375 542714f4-19e9-0310-aa3c-eee0fc999fb1
less polluted. Between build systems, IDEs and IDE-specific-build-systems we've
got half a dozen metafiles knocking around the top-level directory. It's
mayhem.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6359 542714f4-19e9-0310-aa3c-eee0fc999fb1
Narya's strict approach to over the wire compatibility is not so nice when you
have cross-language clients that can't be updated at the same time as the
server.
Maybe we should consider a new over-the-wire format for C++ clients that is
more like pbuffers, which the Narya server could translate to and from Java
Streamable instances, and the C++ side could either use pbuffers directly or
have a similarly change resilient I/O layer that turned over-the-wire data into
C++ objects that mirrored (a potentially out of date) version of their Java
counterparts.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6358 542714f4-19e9-0310-aa3c-eee0fc999fb1
Events originating in Actionscript need to use that class because
we have no generic List class in actionscript. For things that
originate on the server this isn't a problem:
java array -> Array, and java List -> Array
But for things originating on the actionscript client, any array
will become a java array unless we use StreamableArrayList.
So: maybe it's time to add List to the aspirin library. :|
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6354 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne