SuperDevMode and APT

[Stefano Ciccarelli]

Hello,

I'm poking with SuperDevMode just to understand how it works and I faced the first problem: how to deal with APT generated classes? They are generated to .apt_generated directory and aren't found by CodeServer, on the other side I can only specify one dir as -src to CodeServer.

Ideas?

--
Nel mondo esistono 10 categorie di persone, quelle che capiscono il binario e quelle che non lo capiscono.

[Jens]

Just put update the classpath, e.g. 

java -cp ./src:./.apt_generated:<other project dependencies> com.google.gwt.dev.codeserver.CodeServer

-- J.

[Thomas Broyer]

Are you sure "-src src -src .apt_generated" doesn't work?

[Stefano Ciccarelli]

Yes, I've tried it and doesn't work, but the -cp solution works well.

Now I have to understand how to deal with gwt-rpc because the server misses .gwt.rpc files...

2012/6/8 Thomas Broyer <t.br...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/ovaa4RN1sqMJ.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Thomas Broyer]

On Friday, June 8, 2012 2:04:48 PM UTC+2, Stefano Ciccarelli wrote:

Yes, I've tried it and doesn't work, but the -cp solution works well.

Now I have to understand how to deal with gwt-rpc because the server misses .gwt.rpc files...

CodeServer is only about the "code server" part [1] (although it can serve your static resources too, for cases where you don't have server-side code), you still need a Servlet container if you have server-side code.

[1] https://developers.google.com/web-toolkit/doc/latest/DevGuideCompilingAndDebugging#DevGuideDevMode

[Stefano Ciccarelli]

I know, I'm using App Engine as a servlet container. But the problem is to generate .gwt.rpc files that are compatibles with the compiled javascript generated by SuperDevMode.

2012/6/8 Thomas Broyer <t.br...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/JBlBvMXgmrYJ.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Thomas Broyer]

On Friday, June 8, 2012 2:18:28 PM UTC+2, Stefano Ciccarelli wrote:

I know, I'm using App Engine as a servlet container. But the problem is to generate .gwt.rpc files that are compatibles with the compiled javascript generated by SuperDevMode.

Oops, sorry; I read too fast.

Switch to RequestFactory? ;-)

More seriously, I doubt it'll ever be possible to use GWT-RPC with SuperDevMode, due to how/where it generates its output; though maybe you could tweak the way serialization policies are loaded on the server-side? (hmm, with AppEngine, that might be impossible, as you'd have to access files on the file-system; or maybe set SuperDevMode's workDir as a subfolder of your -war?)

[Stefano Ciccarelli]

The .gwt.rpc files are correctly generated in the war relative to the CodeServer workDir, I have to found a way to copy them to the container war when they change (not quite often), would be nice if the CodeServer could do that for me :)

2012/6/8 Thomas Broyer <t.br...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/Rj4sG6PpW_oJ.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Andrea Boscolo]

I can confirm that copying the CodeServer's .gwt.rpc files in the local war dir, works but it's a pain: every time they change, they need to be copied.
Using a -workDir under the war didn't work for me. The CodeServer output directory structure does not help.
In http://tbroyer.posterous.com/how-does-gwts-super-dev-mode-work (thanks for the clarifications Thomas) is it said that can be possible to override loadSerializationPolicy to search for the SuperDevMode app space. Haven't tried yet, I'll find the time to check this out.
Anyway, seems strange that the new development mode does not work well with GWT-RPC. Probably I see the problem from the wrong point of view.

On Friday, June 8, 2012 3:36:13 PM UTC+2, Stefano Ciccarelli wrote:

The .gwt.rpc files are correctly generated in the war relative to the CodeServer workDir, I have to found a way to copy them to the container war when they change (not quite often), would be nice if the CodeServer could do that for me :)

2012/6/8 Thomas Broyer <t.br...@gmail.com>

On Friday, June 8, 2012 2:18:28 PM UTC+2, Stefano Ciccarelli wrote:

I know, I'm using App Engine as a servlet container. But the problem is to generate .gwt.rpc files that are compatibles with the compiled javascript generated by SuperDevMode.

Oops, sorry; I read too fast.

Switch to RequestFactory? ;-)

More seriously, I doubt it'll ever be possible to use GWT-RPC with SuperDevMode, due to how/where it generates its output; though maybe you could tweak the way serialization policies are loaded on the server-side? (hmm, with AppEngine, that might be impossible, as you'd have to access files on the file-system; or maybe set SuperDevMode's workDir as a subfolder of your -war?)

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/Rj4sG6PpW_oJ.

To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsub...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Thomas Broyer]

On Wednesday, June 13, 2012 7:53:35 PM UTC+2, Andrea Boscolo wrote:

I can confirm that copying the CodeServer's .gwt.rpc files in the local war dir, works but it's a pain: every time they change, they need to be copied.
Using a -workDir under the war didn't work for me. The CodeServer output directory structure does not help.

That was: in addition to the following (loadSerializationPolicy), and for AppEngine (because you cannot use java.io.File to look outside your WAR –I'm not even sure you can use it to look inside it, but maybe you could use ServletContext#getResourcePaths to find the latest compilation from SuperDevMode and then use getResourceAsStream to load the gwt.rpc file from there–)

 

In http://tbroyer.posterous.com/how-does-gwts-super-dev-mode-work (thanks for the clarifications Thomas) is it said that can be possible to override loadSerializationPolicy to search for the SuperDevMode app space. Haven't tried yet, I'll find the time to check this out.
Anyway, seems strange that the new development mode does not work well with GWT-RPC. Probably I see the problem from the wrong point of view.

As I wrote on my blog, SuperDevMode (currently) only handles client-side code, and GWT-RPC needs both sides to be in perfect sync.

[Paul Robinson]

On 13/06/12 18:53, Andrea Boscolo wrote:
> I can confirm that copying the CodeServer's .gwt.rpc files in the local war dir, works but it's a pain: every time they change, they need to be copied.

There's an alternative to copying gwt.rpc files. I've changed my app so that when it looks for the serialization policy, and it can't find it, it will ask the code server for it. You just need to parse the module base URL to get the module name, and then use the strong name provided to generate the appropriate URL, something like:
http://localhost:9876/modulename/strongname.gwt.rpc

All I need to do now is to add the codeserver URL as a parameter in web.xml so that this feature can be enabled/disabled so it doesn't happen in production.

I don't know whether this technique would work on GAE as well.

Paul

[Stefano Ciccarelli]

Great idea!

It should work on GAE too using UrlFetch api to talk with the code server.

Could you share some pieces of code, please?

-- 
Inviato con Sparrow

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To post to this group, send email to google-we...@googlegroups.com.

To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

[Paul Robinson]

Here are code fragments for you. It would be good if something like this could be built in to GWT rather than having everybody implement similar code.

    private static final String CODE_SERVER_URL_KEY = "CodeServerURL";

    public void init(ServletConfig config) throws ServletException
    {
        m_codeServerURL = config.getInitParameter(CODE_SERVER_URL_KEY);
       
        if (m_codeServerURL != null && m_codeServerURL.charAt(m_codeServerURL.length()-1) != '/')
            m_codeServerURL = m_codeServerURL + "/";
    }

Then, I override doGetSerializationPolicy and the part of the code that loads from the code server looks like this:
            boolean endsWithSlash = moduleBaseURL.charAt(moduleBaseURL.length()-1) == '/';
           
            String tmp = moduleBaseURL;
            if (endsWithSlash)
                tmp = tmp.substring(0, tmp.length()-1);
           
            int lastSlash = tmp.lastIndexOf('/');
            String moduleName = lastSlash < 0 ? tmp : tmp.substring(lastSlash+1, tmp.length());
            try
            {
                url = new URL(m_codeServerURL + moduleName + "/"
                        + SerializationPolicyLoader.getSerializationPolicyFileName(strongName));
            }
             catch (MalformedURLException mue)
            {
                s_logger.debug("Could not read the policy file '" + url + "'", ioe);
                return null; // null return is then converted into throwing an exception
            }
           
            InputStream is = null;

            try
            {
                is = url.openStream();
                s_logger.debug("Loading serialization policy from code server");
            }
            catch (IOException ioe2)
            {
                s_logger.debug("Could not read the policy file '" + url + "'", ioe);
                return null; // null return is then converted into throwing an exception
            }

Paul

[Thomas Broyer]

On Friday, June 15, 2012 9:00:55 AM UTC+2, Paul Robinson wrote:

Here are code fragments for you. It would be good if something like this could be built in to GWT rather than having everybody implement similar code.

Keep in mind that SuperDevMode is experimental.

It will probably evolve to the point where GWT-RPC won't be an issue, and this workaround won't be needed anymore, so there's no point in building it within GWT at this point.

[Ajax]

In addition to the aforementioned .rpc file lookup fix,

you may also want to put up a servlet filter to catch all requests for files on a given module's base url (easy if your rpc urls don't have . in them;), 
and simply proxy those file requests to the codeserver (HttpClient / UrlFetch) when on localhost (or if config property set).

This way, from the client's perspective, all files originate from the application host.

Doing this will also enable source map support and avoid any cross-domain server issues if you're serving files into a restricted zone, like flash player.

If you catch 404s to the code server, you can just forward the request to the production-mode static files compiled in your war. 

The other option same-domain option is to proxy requests that the code server misses to the application server,

but this is much, much slower, since it costs more to tax every ajax request instead of every static file request.

[Frank Ren]

It's been two years. And, I was just push into this problem by Chrome dropping support for GWT plugin. i.e. I have to downgrade Firefox to version 24, or to struggle with super dev mode.

However, both running a Firefox version 24, and a super dev mode lead me to the following exception, even with Paul's code to override RemoteServiceServlet.
com.google.gwt.user.client.rpc.IncompatibleRemoteServiceException: This application is out of date, please click the refresh button on your browser.

Is GWT going to get a death sentence?

[Paul Robinson]

On 24 May 2014 05:03, "Frank Ren" <renfe...@gmail.com> wrote:
>
> It's been two years. And, I was just push into this problem by Chrome dropping support for GWT plugin. i.e. I have to downgrade Firefox to version 24, or to struggle with super dev mode.
>
> However, both running a Firefox version 24, and a super dev mode lead me to the following exception, even with Paul's code to override RemoteServiceServlet.
> com.google.gwt.user.client.rpc.IncompatibleRemoteServiceException: This application is out of date, please click the refresh button on your browser.

It should still work, at least with 2.5.1. I've not used 2.6.1 yet.

>
> Is GWT going to get a death sentence?

Eventually, yes because everything dies. But not now.

It was a technological miracle that DevMode worked, and it's not really a surprise that the browsers are moving away from supporting the kind of synchronous plugins that it required.

SDM is not perfect, but it's quite usable. If you'd never seen DM, you might well have thought SDM amazingly good. It's getting better too, with Eclipse support on the way.

Paul

[Dennis Haupt]

i'd stick to old versions and switch to sdm once ides support good browser remote debugging with good sourcemap support.

if i still used the gwt.

--

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.