Stable .rpc files

[P.G.Taboada]

Hi there,

are there any chances to get stable .rpc files in upcoming releases? I remember that the images generated by imagebundle had stable filenames across compiles, somehow dependent from images hashcode.

I have seen comments here and there praising "rest" or "autobeans+requestbuilder", 

but neither one of the approaches provide polymorphism and as far as I know both would have troubles with object cycles.

IMHO, rest or auto beans are wrong for client-server on so many levels that I stopped counting. I am expecting a flame war on this statement, but I am very convinced that none of them do really solve issues I have in client-server communication in product development.

I am using the command pattern and very happy to have with multiple versions, batching, recording, reuse, central exception handling, etc. 

I have a plain pojo communication model, and gwt-rpc simply gets things done pretty well. Unfortunately, the .rpc files are not stable - and they are the last mile for me to have real zero downtime deployments.

I even do export my dispatch service as httpinvoker/ exporter and can reuse the same communication layer for pure java clients. I have a proprietary http/json converter in a servlet for my iOS app. But this is another story and does not have the issues I have on the GWT side with the .rpc files.

I am willing to switch at any moment, all I need is a GWT-RPC replacement that handles 

<R extends Result> R execute(Action<R> action) throws DispatchException;

properly. It would take me no time to change, all communication runs over pojis/ pojos.

Any suggestions?

brgds,

Papick

[Jens]

At work when I upgrade our app and rpc policy files have changed users get a message "App has been updated and will now be reloaded". The app reloads itself and the user can continue to work using the updated app. Is that already too much of a downtime for you?

AutoBeans indeed do not support polymorphism and JSOs have different restrictions (all methods must be final) however that must not be a problem. For example RequestFactory supports polymorphism even though it uses AutoBeans encode/decode the data to transfer.

One "easy" thing you could try is to create an additional service that has String execute(String) and then use piriti for de-/serialization of your commands. I have never used it but it seems to look quite good: https://github.com/hpehl/piriti/wiki/Features

-- J.

[Michael Joyner]

On 06/10/2014 01:42 PM, Jens wrote:
> At work when I upgrade our app and rpc policy files have changed users
> get a message "App has been updated and will now be reloaded". The app
> reloads itself and the user can continue to work using the updated
> app. Is that already too much of a downtime for you?

What is the procedure you use for detecting app and rpc policy file change?

[Jens]

What is the procedure you use for detecting app and rpc policy file change?

We have implemented a couple of things:

1.) We treat every IncompatibleRemoteServiceException and every SerializationException as indication that the app has been updated because both exceptions should never occur otherwise (unless you have not tested your app before it goes into production). So whenever they are thrown we treat it as app update.

2.) Whenever a split point can not be loaded it is likely that the app has been updated and permutation hashes have changed. We treat that as app update as long as the browser is online.

3.) We have a dynamic host page that contains some embedded JSON data. This data contains an app version string generated on the server based on the context root the app has been deployed to, e.g. hash("/app-<build-timestamp>"). The app extracts that server version from the host page and sends it back to the server with each request. A servlet filter is then checking this version against the current server version. If they are different a HTTP status code is send back to the client which causes the client to reload itself because the server has been updated.

The first two have been used while we had a static host page. The second and the third one are used now as we switched to a dynamic host page. We still need the second option because our JavaScript is served from a plain web server and not from the Java app server. Thus the servlet filter can not check the app version in case of split point downloads. If you don't have that separation I think you could replace the split point download strategy of GWT with a custom one which also sends the app version to the server so you can check it.

Works pretty well for us so far.

-- J.

[P.G.Taboada]

My build process stores build/ version information into the host-file (js dictionary) and I have a servlet that delivers same information on the server side. Client asks server, if server has different build/ version number, client side reloads.

[P.G.Taboada]

Basically same procedure here. I still have a reload when I don't need one, and changing roc files are a no-go when thinking of phone gap app deployments.

[Michael Joyner]

On 06/12/2014 04:56 AM, P.G.Taboada wrote:
> My build process stores build/ version information into the host-file
> (js dictionary) and I have a servlet that delivers same information on
> the server side. Client asks server, if server has different build/
> version number, client side reloads.

What is the easiest way to store a build number as part of the project
when using a stock Eclipse project setup?

[Joseph Lust]

@Michael, welcome the the Chicken and the Egg problem.

In order to build the build number (I'm assuming you mean rev number from git/svn), you've first got to commit that code. Then, you've got be build it, but the code never had the commit number in it, since it could not be known pre-commit. 

To get around this in the past I have used either of the following:

• Written a GWT compiler plugin to generate the impl of a BuilderNumberProvider class. This plugin grabbed the rev # from Maven then then wrote and compiled an extra class with that value in it.
• Copied the build number into the WAR and then injected it into the app page (i.e. jsp) and had GWT read it via JSNI at the EntryPoint.

Hope that helps.

Sincerely,

Joseph

[Michael Joyner]

Ack ...

What about a simple build timestamp?

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Joseph Lust]

If that works for you. Personally, I expected idempotency in builds.

Sincerely,

Joe

[Michael Joyner]

On 06/17/2014 06:25 PM, Joseph Lust wrote:
> If that works for you. Personally, I expected idempotency in builds.

We aren't deploying each recompile to the production site, and it is
simple enough to add a hook to ignore a serial diff it is running
locally by checking URL.

[P.G.Taboada]

Fully agree. Setup a build tool is nothing too complex to do. And the gain in lib dependency management and documentation is huge.

We are using gradle as often as we can, even have a plugin open sourced at github. Currently I use a gradle "info" plugin that extracts some infos I can reuse for token replacement.

... but ... we are drifting away. 

I really would like to have some comments on the topic "stable .rpc files"

:-)