CodeServer with Bookmarklets not working in GWT 2.7 (2nd request)

Brandon Donnelson

unread,

Sep 8, 2016, 11:53:43 PM9/8/16

to GWT Contributors

There are some complicated enterprise configurations where the application is dependent on other applications. And staging this on an external web server is challenging. I've seen enough web server configurations to want bookmarklets to work. I know it's not the preferred way to boot up SDM, but it would be quite handy to have bookmarklets fire of the compile and link up the resources.

Does anybody have a workaround for the bookmarklet's javascript? And could we get this fixed in GWT 2.8?

The project below, the first compile works just fine using the CodeServer and firing off the compile from the bookmarklet. But then the second compile request to the code server fails because it must not be sending some query string property so it only binds to one permutation.

```

Turning off precompile in incremental mode.

Super Dev Mode starting up

workDir: /var/folders/x8/9wz7qtw96t7grkdyjw1l61p40000gn/T/gwt-codeserver-5458587005926250195.tmp

Loading Java files in com.gonevertical.snowy.SnowyMountainProject.

Module setup completed in 19801 ms

Sep 09, 2016 11:45:00 AM org.eclipse.jetty.server.Server doStart

INFO: jetty-8.y.z-SNAPSHOT

Sep 09, 2016 11:45:00 AM org.eclipse.jetty.server.AbstractConnector doStart

INFO: Started SelectChann...@127.0.0.1:9876

The code server is ready at http://localhost:9876/

GET /recompile/SnowyMountainProject

Job com.gonevertical.snowy.SnowyMountainProject_1_0

starting job: com.gonevertical.snowy.SnowyMountainProject_1_0

binding: gxt.device=desktop

binding: gxt.user.agent=chrome

binding: locale=default

binding: user.agent=safari

binding: user.agent.os=mac

Compiling module com.gonevertical.snowy.SnowyMountainProject

Unification traversed 32527 fields and methods and 3143 types. 3090 are considered part of the current module and 3090 had all of their fields and methods traversed.

Compiling 1 permutation

Compiling permutation 0...

Linking per-type JS with 3074 new types.

prelink JS size = 5557062

prelink sourcemap = 5557062 bytes and 143563 lines

postlink JS size = 5235031

postlink sourcemap = 5235031 bytes and 135811 lines

Source Maps Enabled

Compile of permutations succeeded

Compilation succeeded -- 14.026s

Linking into /var/folders/x8/9wz7qtw96t7grkdyjw1l61p40000gn/T/gwt-codeserver-5458587005926250195.tmp/com.gonevertical.snowy.SnowyMountainProject/compile-2/war/SnowyMountainProject; Writing extras to /var/folders/x8/9wz7qtw96t7grkdyjw1l61p40000gn/T/gwt-codeserver-5458587005926250195.tmp/com.gonevertical.snowy.SnowyMountainProject/compile-2/extras/SnowyMountainProject

Link succeeded

Linking succeeded -- 0.693s

14.859s total -- Compile completed

GET /recompile/SnowyMountainProject

Job com.gonevertical.snowy.SnowyMountainProject_1_1

starting job: com.gonevertical.snowy.SnowyMountainProject_1_1

binding: locale=default

binding: user.agent=safari

Compiling module com.gonevertical.snowy.SnowyMountainProject

[ERROR] Current binding properties are expanding to more than one permutation but per-file compilation requires that each compile operate on only one permutation.

[WARN] recompile failed

[WARN] continuing to serve previous version

GET /recompile/SnowyMountainProject

Job com.gonevertical.snowy.SnowyMountainProject_1_2

starting job: com.gonevertical.snowy.SnowyMountainProject_1_2

binding: locale=default

binding: user.agent=safari

Compiling module com.gonevertical.snowy.SnowyMountainProject

[ERROR] Current binding properties are expanding to more than one permutation but per-file compilation requires that each compile operate on only one permutation.

[WARN] recompile failed

[WARN] continuing to serve previous version

```

Thanks,

Brandon

Brandon Donnelson

unread,

Sep 9, 2016, 12:01:54 AM9/9/16

to GWT Contributors

Workaround, hit dev mode off then compile again.

Thomas Broyer

unread,

Sep 9, 2016, 3:20:31 AM9/9/16

to GWT Contributors

Doesn't CodeServer accept -setProperty? You could use that to pinpoint the property values so you only have one permutation when only user.agent is given.

Brandon Donnelson

unread,

Sep 9, 2016, 10:23:30 PM9/9/16

to GWT Contributors

I haven't dug in yet, just wanting to use it. That sounds promising. Using bookmarlets doesn't work when the module is embedded in another iframe. so the next issue I need to deal with is helping detect the module when it's not in the main body but in another iframe of the document.

The other workaround is to implant the project.nocache.js js launching in the war and send it off to the external server. So this makes another problem I have hit a couple times. Where I change the var hostName = "127.0.0.1"; to a specific ip because I loaded the app with project.nocache.js. I like this hack but I'm wishing I could set that in the code server launcher arguments.

Anyway it's all about using an external server.

Thomas Broyer

unread,

Sep 10, 2016, 4:43:55 AM9/10/16

to GWT Contributors

How about proxying through a local server that would intercept the nocache.js and route everything else to your external server? This is basically how webpack devserver and browserSync work in the JS land.

Brandon Donnelson

unread,

Sep 12, 2016, 3:24:54 PM9/12/16

to GWT Contributors

Proxying wasn't an option for developers because of the I.T. security protocols. Besides it feels a bit overcomplicated to have to set up a channel back to the code server. I think it would be easier to clobber the codeserver api with a workaround and setting the hosteName and hand that to the developers. I'm contemplating on forking the code server for GWT 2.7 users to provide a workaround for the hostName through the program arguments.

On Sat, Sep 10, 2016 at 1:43 AM Thomas Broyer <t.br...@gmail.com> wrote:

How about proxying through a local server that would intercept the nocache.js and route everything else to your external server? This is basically how webpack devserver and browserSync work in the JS land.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/13bfb1ba-f2fb-40cf-afda-c9902d016cb3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Brandon Donnelson
GXT Support Engineer

Join me at SenchaCon 2016!

JonL

unread,

Sep 13, 2016, 11:53:27 AM9/13/16

to GWT Contributors

I've had to do this when working on a sdm compiled application in a web wrapper on ios, instead of a proxy, I wrote a custom nocache.js that replaces the one generated by sdm and adds a url parameter to tell it the remote server to connect to where the codeserver is running, allowing me to debug the application running directly on the ipad correctly.

Here is a gist of a sligtly modified version of the nocache.js replacing the module name with "module_name":

https://gist.github.com/jonl-percsolutions-com/403ec9ba1bf50a6abcb0db852b171d0c

So I just run my gwt-compile, replace the nocache.js and then create the war for deployment. The when accessing the url, provide the url paramter "remote_server=http://ip:port".

Not sure if this will be what you need 100% but should work instead of setting up a proxy or clobbering the codeserver api.

On Monday, September 12, 2016 at 12:24:54 PM UTC-7, Brandon Donnelson wrote:

Proxying wasn't an option for developers because of the I.T. security protocols. Besides it feels a bit overcomplicated to have to set up a channel back to the code server. I think it would be easier to clobber the codeserver api with a workaround and setting the hosteName and hand that to the developers. I'm contemplating on forking the code server for GWT 2.7 users to provide a workaround for the hostName through the program arguments.

On Sat, Sep 10, 2016 at 1:43 AM Thomas Broyer <t.br...@gmail.com> wrote:

How about proxying through a local server that would intercept the nocache.js and route everything else to your external server? This is basically how webpack devserver and browserSync work in the JS land.

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

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/13bfb1ba-f2fb-40cf-afda-c9902d016cb3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Daniel Kurka

unread,

Sep 13, 2016, 12:08:22 PM9/13/16

to GWT Contributors

This is what recompile on reload is for, you can simply always load:

http://[sdmhost]:[sdmport]/recompile-requester/[module]

On Tue, Sep 13, 2016 at 5:53 PM JonL <jo...@percsolutions.com> wrote:

I've had to do this when working on a sdm compiled application in a web wrapper on ios, instead of a proxy, I wrote a custom nocache.js that replaces the one generated by sdm and adds a url parameter to tell it the remote server to connect to where the codeserver is running, allowing me to debug the application running directly on the ipad correctly.

Here is a gist of a sligtly modified version of the nocache.js replacing the module name with "module_name":
https://gist.github.com/jonl-percsolutions-com/403ec9ba1bf50a6abcb0db852b171d0c

So I just run my gwt-compile, replace the nocache.js and then create the war for deployment. The when accessing the url, provide the url paramter "remote_server=http://ip:port".

Not sure if this will be what you need 100% but should work instead of setting up a proxy or clobbering the codeserver api.

On Monday, September 12, 2016 at 12:24:54 PM UTC-7, Brandon Donnelson wrote:
Proxying wasn't an option for developers because of the I.T. security protocols. Besides it feels a bit overcomplicated to have to set up a channel back to the code server. I think it would be easier to clobber the codeserver api with a workaround and setting the hosteName and hand that to the developers. I'm contemplating on forking the code server for GWT 2.7 users to provide a workaround for the hostName through the program arguments.

On Sat, Sep 10, 2016 at 1:43 AM Thomas Broyer <t.br...@gmail.com> wrote:

How about proxying through a local server that would intercept the nocache.js and route everything else to your external server? This is basically how webpack devserver and browserSync work in the JS land.

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

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/13bfb1ba-f2fb-40cf-afda-c9902d016cb3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Brandon Donnelson
GXT Support Engineer
Join me at SenchaCon 2016!

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/274f1c7b-8267-4164-8d11-ab3e64dd9721%40googlegroups.com.

Reply all

Reply to author

Forward