Hello.
Browsers running our GWT application (version 2.11) have recently (this
week) started reporting errors like this one:
[{"age":41550,"body":{"columnNumber":192,"id":"UnloadHandler
","lineNumber":3210,"message":"Unload event listeners are deprecated and
will be
uiring a reload.
So it looks like its better to implement IsSerializable rather than
Serializable.
What do you think? Am I missing something?
On Wed, Jul 19, 2017 at 12:22 PM, Thomas Broyer <t.bro...@gmail.com> wrote:
>
>
> On Tuesday, July 18, 2017 at 6:15:23 PM UTC+2, Óscar Frías B
return an exception.
Any ideas on how to implement this?
On Tue, Jul 18, 2017 at 7:34 PM, Michael Joyner <mich...@newsrx.com> wrote:
> We use https://github.com/realityforge/gwt-cache-filter to help deal with
> caching issues.
>
> On 07/18/2017 12:15 PM, Óscar Frías Barranco wrote
Hi.
When we modify the code of our GWT application, in particular the classes
that travel through GWT calls, these exceptions are generated for many
users for a few hours:
com.google.gwt.user.client.rpc.SerializationException: Type '.' was not
assignable to
> Do you have a step by step guide to run the closure compiler externally ?
>>
>
> Basically you would need to replicate what has been done programmatically
> in the removed ClosureJsRunner class. See commit
>
> https://github.com/gwtproject/gwt/commit/162ccc9c9112a09bf9e
> a046da95760f5f1886b72
>
>
> And why don't keep it experimental too in 2.8 instead of removing it?
>>
>
> Why keeping it if it's only half baked into GWT and you can run it
> externally as well?
>
Do you have a step by step guide to run the closure compiler externally ?
--
You received this message because you are
> Do you plan to bring Closure Compiler (-XenableClosureCompiler option)
>> back to GWT? It was very useful for us.
>>
>
> No. It was experimental and had some rough edges that haven't been fully
> implemented.
>
And why don't keep it experimental too in 2.8 instead of removing it?
--
You
Hi.
We are trying to move our website from GWT 2.7 to 2.8 but we have found
that GWT 2.8 generates code which is significantly heavier.
For example, these are the sizes for one of the permutations:
GWT 2.7 + Closure Compiler: 590 KB
GWT 2.7 without Closure Compiler: 664 KB
GWT 2.8 (no Closure
We haven't done anything else for the moment. We hope iOS 6.1 or the next
version of GWT fixes it.
By the way, probably related bug:
http://code.google.com/p/google-web-toolkit/issues/detail?id=7831
Maybe if you (and more people) star it the GWT team will prioritize it (and
will either fix
No. It still persists.
Are you facing a similar problem ?
Oscar
El lunes, 14 de enero de 2013 20:54:41 UTC+1, mkn escribió:
Hi
Could you solve your problem in the meantime?
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To view
OK, thanks, I have reported the issue here:
http://code.google.com/p/google-web-toolkit/issues/detail?id=7808
El domingo, 25 de noviembre de 2012 03:26:22 UTC+1, Thomas Broyer escribió:
On Monday, November 19, 2012 7:45:16 PM UTC+1, Óscar Frías Barranco wrote:
Hello.
We are trying
Hello.
We are trying to implement Runtime Locales as explained in:
https://developers.google.com/web-toolkit/doc/latest/DevGuideI18nLocale#RuntimeLocales
We are using a gwt.xml like this one:
module
inherits name='com.google.gwt.user.User'/
inherits
completely random.
El martes, 6 de noviembre de 2012 19:51:51 UTC+1, Óscar Frías Barranco
escribió:
Hi again.
We have found that compiling with -XenableClosureCompiler hides the
problem or at least mitigates it.
I have no idea about what Closure Compiler does to GWT generated
javascript
, 2012 11:54:57 AM UTC+1, Óscar Frías Barranco
wrote:
Just let me clarify that the ClosureCompiler does not fix the issue, it
just makes it less frequent.
The issue is so weird that you can load a GWT page without any error and
then just reload the same page to find that now GWT javascript
occurs.
Maybe that gives you some hints which generated JS code exactly causes the
unexpected exception.
-- J.
Am Mittwoch, 7. November 2012 17:01:46 UTC+1 schrieb Óscar Frías Barranco:
Yes, the error that we are gettting is a ClassCastException.
Oscar
El miércoles, 7 de noviembre de
Hello.
Our GWT application crashes when running on an iPad with iOS 6.0.1.
This is not related to the POST caching issue because we already added
Cache-Control and Expires headers to GWT RPC replies and now they are not
cached.
We have debugged the app by adding Window.alert() calls and we
Hello.
We just override the method onAfterResponseSerialized from
RemoteServiceServlet in the RPC services implementation and this fixes this
issue:
@Override
protected void onAfterResponseSerialized(String serializedResponse) {
HttpServletResponse response =
, Óscar Frías Barranco
escribió:
Hello.
Our GWT application crashes when running on an iPad with iOS 6.0.1.
This is not related to the POST caching issue because we already added
Cache-Control and Expires headers to GWT RPC replies and now they are not
cached.
We have debugged the app
Which is the best place to put the gwt script in the HTML page from a
performance point of view (page speed) ?
I mean to minimize the load time of a page that contains some HTML
code in addition to the GWT module.
Is it better to put it at the end of the head section (immediately
before the /head
. The html-code generate the page almost
instantly. GWT metod RootPanel.get(id) also work very quickly.
Almost all time of page generation will take the loading of gwt-
module. So place your gwt-application where it is more convenient to
you.
On 13 апр, 13:51, Óscar Frías ofr...@gmail.com wrote
I am migrating a GWT application from GWT 1.5 to GWT 1.6.4
The application uses the SliderBar widget (with some changes).
SliderBar calls DOM.getAbsoluteLeft() to obtain the position of the
knob.
The problem is that this code was working OK in all the browsers when
we were using GWT 1.5.3.
Now,
method before constructing some
widgets should leave them in an illegal state.
On Dec 24 2008, 4:58 pm, Óscar Frías ofr...@gmail.com wrote:
Hello.
We have detected that our web application throws this Exception
sometimes:
java.lang.IllegalStateException: Should only call onDetach when
Hello.
We have detected that our web application throws this Exception
sometimes:
java.lang.IllegalStateException: Should only call onDetach when the
widget is attached to the browser's document
We detect these exceptions because we have implemented a custom
exception handler that reports
23 matches
Mail list logo
