[gwt-contrib] Re: calling onLoadErrorFn on permutation 404
I'm trying to hook into the failure of when a client loads the .nocache.js from one version, but tries to get the permutation from another. Hm interesting, we never run into this. How do you update your app? Maybe we also suffer this small window but never noticed it. We deploy a second app on app servers and once that is done we tell load balancers to redirect to the new app. Now a couple of things can happen: - User is logged in and has all split points = GWT-RPC Exception might occur = app reloads - User is logged in and tries to download old split point (404) = Caught on split point level and app reloads - User is not logged in = user will load new nocache.js file and gets new app -- J. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/4607c79c-5677-45fd-a48e-7ddb2cac0c5a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: calling onLoadErrorFn on permutation 404
On Monday, October 6, 2014 10:25:24 AM UTC+2, Jens wrote: I'm trying to hook into the failure of when a client loads the .nocache.js from one version, but tries to get the permutation from another. Hm interesting, we never run into this. How do you update your app? Maybe we also suffer this small window but never noticed it. We deploy a second app on app servers and once that is done we tell load balancers to redirect to the new app. Now a couple of things can happen: - User is logged in and has all split points = GWT-RPC Exception might occur = app reloads - User is logged in and tries to download old split point (404) = Caught on split point level and app reloads - User is not logged in = user will load new nocache.js file and gets new app - User starts loading old nocache.js, you tell load balancers to redirect to the new app, the nocache.js runs and tries to load an old permutation from a new server where it doesn't exist. I suppose Stephen's deployment strategy is different, with some servers still serving the old app while others already serve the new app, and the load balancer could direct traffic to either server; but the end result is the same. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/a1ca5767-e08e-4874-aeb6-fd6f7ef73b19%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: calling onLoadErrorFn on permutation 404
- User starts loading old nocache.js, you tell load balancers to redirect to the new app, the nocache.js runs and tries to load an old permutation from a new server where it doesn't exist. Right. I suppose Stephen's deployment strategy is different Yeah, slightly. Currently, if we have two servers running, our deployment script will start another two (by increasing the AWS auto scaling group size to 4), which means AWS will immediately add them to the AWS ELB when they boot. Our script then waits to shut down the old servers until it's verified both new ones are running/healthy. So, the window where we could have both running is ~3-5 minutes long. That said, our new deployment scripts (that we just haven't moved to yet), start a completely new AWS auto scaling group for the deployment, let all the new instances start in there (without being added to the ELB), and then do a mass register/deregister of the machines with the ELB. Which will have a much smaller window, but it's still not atomic. - Stephen -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/20141006085918.42db61c4%40sh9. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Code for GSS support (GssResource) pushed. Please review.
Hi, I've pushed the code for the so called GssResource. The code has been split in two patches: - The first one contains the code for the converter. The converter can be used in order to convert the existing css files to a GSS compatible file. - The second one contains the code for the generator that parses and compiles the GSS file and produces the implementation of the related CssResources. It would be nice to get this code in GWT 2.7, so could you review the two patches ? The GSS support won't be enabled by default. In order to enable it, you will have to set the configuration property named CssResource.enableGss to true. When enabled, all of the CssResource will be generated by using the GssGenerator. If your application is using a third-party library that defines some CssResource that aren't converted to GSS, you can also enable the in-memory conversion (of css files with .css extension) to GSS by setting the configuration property CssResource.legacy to true. This conversion can run in strict (throw error if the original file contains some errors) or lenient mode (does its best to fix the original file) . Now I think we should allow the inverse: give the ability to third party libraries to use GSS in their CssResource even if the CssResource.enableGss is set to false. This could be done by either using an annotation or by using a configuration property in the module file. What do you think it would be the best ? I'm more in favor of the annotation. Julien -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D4HmWFv0V2BVi5qf3B8Jdjkt-eUXZD4hBLvuM5X_U5qxQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Code for GSS support (GssResource) pushed. Please review.
Now I think we should allow the inverse: give the ability to third party libraries to use GSS in their CssResource even if the CssResource.enableGss is set to false. This could be done by either using an annotation or by using a configuration property in the module file. You said that CssResource.enableGss means that CssResources are now generated using GssGenerator. If a library wants to use GSS shouldn't it use GssResource directly instead of CssResource? In that case GssResources could always be generated using GssGenerator regardless of CssResource.enableGss settings. I don't think libraries should take their existing CssResources and add CSS3 stuff to it. I would force them to use GssResource then. Wasn't the plan to remove CssResource (and the in-memory conversation) in GWT 3.0 anyways? -- J. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/d4cf2cb9-ddea-4ef9-a8d1-73eea1ee402e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Code for GSS support (GssResource) pushed. Please review.
Oh I forgot to mention that we had decided to use only the CssResource interface and not create a new GssResource interface. And we use the extension of the file in order to know if the file has to be converted or not. On Oct 6, 2014 8:24 PM, Jens jens.nehlme...@gmail.com wrote: Now I think we should allow the inverse: give the ability to third party libraries to use GSS in their CssResource even if the CssResource.enableGss is set to false. This could be done by either using an annotation or by using a configuration property in the module file. You said that CssResource.enableGss means that CssResources are now generated using GssGenerator. If a library wants to use GSS shouldn't it use GssResource directly instead of CssResource? In that case GssResources could always be generated using GssGenerator regardless of CssResource.enableGss settings. I don't think libraries should take their existing CssResources and add CSS3 stuff to it. I would force them to use GssResource then. Wasn't the plan to remove CssResource (and the in-memory conversation) in GWT 3.0 anyways? -- J. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/d4cf2cb9-ddea-4ef9-a8d1-73eea1ee402e%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/d4cf2cb9-ddea-4ef9-a8d1-73eea1ee402e%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D4h6kyKP06_38PMVTvfhZQXTatkbYSiYnDm7eNKStFcow%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Code for GSS support (GssResource) pushed. Please review.
Oh I forgot to mention that we had decided to use only the CssResource interface and not create a new GssResource interface. And we use the extension of the file in order to know if the file has to be converted or not Oh I see. I think a config property is better since a library might have widgets with inline UiBinder styles and you don't want to force them to declare a CssResource in their widget class just to be able to place an annotation on it. -- J. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/84c99c30-abca-46e4-855b-c2152968ef73%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Code for GSS support (GssResource) pushed. Please review.
In fact, my question is stupid... If third party library want to use GSS, they just have to use file with .gss extension. For inline UiBinder styles, we can add an attribute useGss=true. On Mon, Oct 6, 2014 at 8:41 PM, Jens jens.nehlme...@gmail.com wrote: Oh I forgot to mention that we had decided to use only the CssResource interface and not create a new GssResource interface. And we use the extension of the file in order to know if the file has to be converted or not Oh I see. I think a config property is better since a library might have widgets with inline UiBinder styles and you don't want to force them to declare a CssResource in their widget class just to be able to place an annotation on it. -- J. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/84c99c30-abca-46e4-855b-c2152968ef73%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/84c99c30-abca-46e4-855b-c2152968ef73%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D6Hy4dNtbAoYho7LWxoPduXuLYUot5A1ZwHEh0O3PiWyQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Code for GSS support (GssResource) pushed. Please review.
For inline UiBinder styles, we can add an attribute useGss=true. Hmm but still a bit of work if a library has lots of inline styles and wants to use GSS stuff. A multi-valued config property like CssResource.GssRequired that takes GWT module names could be used to enable GSS for inline styles on a per module basis. -- J. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/8eaf838f-234b-40c0-8adb-ba78a62fb835%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Code for GSS support (GssResource) pushed. Please review.
Hmm but still a bit of work if a library has lots of inline styles and wants to use GSS stuff. If you want to use GSS in all of your inline styles, you have first to convert them to GSS and it will take more time than simply adding an attribute that say that this inline style is using GSS. The problem with UiBinder is that we don't know if the developer is using CSS or GSS because the CssResource interface is generated and we cannot based our logic on the file extension as we do with normal CssResource. I have still to investigate but I'm pretty sure that adding an attribute will be the easiest way to support correctly GSS in uibinder inline style. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D4gaeww%3DY4cTkvNXXKKNmig6_s1CaOpwNAAemHXemb%2BjQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Code for GSS support (GssResource) pushed. Please review.
We worked on a migration plan a few weeks back. I don't think we need to mix css and gss together inside the same app. At this point, the libraries have multiple reasonable options on compatibility: 1- Provide both css and gss file for the resource (recommended). The library will work fine regardless if the app enables gss or not as the right file will be chosen for the app. That's what we will do for internal resources in the SDK. 2- Keep providing the css file and make sure it works in strict mode. The library will work fine in css mode and will work with gss only if the legacy mode is enabled. 3- Keep the old css that requires lenient mode. The library will work fine in css mode and *may* work with gss if lenient legacy mode is enabled. More problematic part is the css inside uibinder. Like you said, simplest option is to introduce a temporary attribute in ui:style tag that marks the content as gss. In this case it is more tricky for the library to support compatibility mode similar to the mode (1) above. Either the lib should write the style that both compiles with css and gss or if it is not feasible then it should extract the resource to a file and follow the two file approach described above. On Mon, Oct 6, 2014 at 12:54 PM, Julien Dramaix julien.dram...@gmail.com wrote: Hmm but still a bit of work if a library has lots of inline styles and wants to use GSS stuff. If you want to use GSS in all of your inline styles, you have first to convert them to GSS and it will take more time than simply adding an attribute that say that this inline style is using GSS. The problem with UiBinder is that we don't know if the developer is using CSS or GSS because the CssResource interface is generated and we cannot based our logic on the file extension as we do with normal CssResource. I have still to investigate but I'm pretty sure that adding an attribute will be the easiest way to support correctly GSS in uibinder inline style. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D4gaeww%3DY4cTkvNXXKKNmig6_s1CaOpwNAAemHXemb%2BjQ%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D4gaeww%3DY4cTkvNXXKKNmig6_s1CaOpwNAAemHXemb%2BjQ%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2FYLyv%3DWYfOi0TqtojPbCTPkgzApW6J3BwnmJP19HVAQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Last call for patches
Hi all, as a reminder: Please make sure to get your patches in for GWT 2.7 until tomorrow (October 7th). -Daniel -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujiot7yhnKTbXepwskgBYxOpqzMEHQMhTc%3D3NHGbMP5%2BDqQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
