GWT 1.5 RC2 now available

[Bruce Johnson]

Hi everyone,

I'd like to announce that we've posted a second release candidate for GWT 1.5 on the downloads page here:

    http://code.google.com/webtoolkit/download.html

GWT 1.5 RC2 includes a number of enhancements and fixes above and beyond those included in the first release candidate. Please see the release notes included in the installation archive for details. We will be continuing to update the public documentation and posting further fun technical details on the Google Web Toolkit blog soon:

    http://googlewebtoolkit.blogspot.com/

-- Bruce, on behalf of the GWT team

[darkchubs]

Hi, I just un-Tared the Linux version and it generates this error:
tar: gwt-linux-1.5.1/doc: Not found in archive
tar: Error exit delayed from previous errors

[Martin]

hello

I updated from 1.5 RC1 to 1.5 RC2 and RPC stopped working in hosted
browser, because client generates differend hash codes for classes and
so server can't find .gwt.rpc file. Compiled version works fine. I
checked all libs twice and I see no problem on my side. Any hint?

2008-08-13 10:27:44,395 INFO / - ERROR: The serialization policy file
'/gofer/gui/A518A9F1A9E3C9FE6760F7DC389F98B1.gwt.rpc' was not found;
did you forget to include it in this deployment?
2008-08-13 10:27:44,396 INFO / - WARNING: Failed to get the
SerializationPolicy 'A518A9F1A9E3C9FE6760F7DC389F98B1' for module
'http://localhost:8080/gofer/gui/'; a legacy, 1.3.3 compatible,
serialization policy will be used. You may experience
SerializationExceptions as a result.
2008-08-13 10:27:44,445 WARN / - Exception while dispatching incoming
RPC call
com.google.gwt.user.client.rpc.SerializationException: Type
'com.mwaysolutions.gofer2.client.dto.pipeline.GetChannelsResult' was
not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' and
did not have a custom field serializer. For security purposes, this
type will not be serialized.
at
com.google.gwt.user.server.rpc.impl.LegacySerializationPolicy.validateSerialize(LegacySerializationPolicy.java:
140)
at
com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serialize(ServerSerializationStreamWriter.java:
585)

I have client and server projects separated. Model objects for both
server and client are the same, except for transient fields.
Thanks for help in advance!

[Miguel Méndez]

I assume that by hash code you mean the strong name of the serialization policy file.  The fact that this changed should not cause a problem if you updated both the client and server to 1.5 RC2.

--
Miguel

[Martin]

I had updated both client and server GWT libraries and recompiled
client and restarted server. For sure I had also deleted old GWT 1.5
RC1 before. Then I tested on linux and my college on windows, but both
behaved in the same way described above. What has changed in RPC since
1.5 RC1? When debugging I see request from the client with such hash
that <hash>.gwt.rpc doesn't exist on the server. What classes/methods
should I debug to give you more information?

On Aug 13, 2:52 pm, "Miguel Méndez" <mmen...@google.com> wrote:
> I assume that by hash code you mean the strong name of the serialization
> policy file.  The fact that this changed should not cause a problem if you
> updated both the client and server to 1.5 RC2.

Thanks in advance.

[Ian Bambury]

Would it be worth mentioning in the release notes that you completely removed public static void onHistoryChanged(String historyToken) from the History class between 1.5.0 and 1.5.1? I mean, it's been there since 1.0.

 

Now you can write a history token without firing the listeners, but you can't fire the listeners without writing a history token.

I'm sure there must be a good reason for the change, but I can't think of one.

 

--
Ian
http://examples.roughian.com
_______________________________________

Stuff the environment - Print this email
_______________________________________

[Patrick]

What is the recommended debugging technique when it works in hosted
mode but not in browser mode?

I seem to have a problem adding items to a Tree, or more specifically,
a Map that holds extra meta data. No issues in hosted mode, breaks in
browser mode. Also works fine with RC1

On Aug 12, 8:48 pm, "Bruce Johnson" <br...@google.com> wrote:

[Hugo Hallqvist]

Hi Martin and list,

I've also got bitten by this problem, and have not found a solution to
it yet. I have a file in the public web directory called
<hashvalue>.gwt.rpc, however when gwt loads the SerializationPolicy,
the strongname is another hashvalue. Where does the strongname come
from?

I've you solve it, please report back your solution.

Regards,

//Hugo

2008/8/13 Martin <m.z...@gmail.com>:

--
Med vänlig hälsning,
Hugo Hallqvist
Dokad Software AB
www.dokad.se

[Sumit Chandel]

Hi darkchubs,

I'm not sure which extraction utility you're using to untar the distribution, but if it offers a preview of what is included in the tar file, can you verify that the 'doc' folder is listed? If not, you might want to try downloading the GWT 1.5 RC2 distro one more time as it's possible that the current version you're trying to untar was corrupted during the download process.

Hope that helps,
-Sumit Chandel

[Sumit Chandel]

Hi Martin,

Something you might want to double-check is that the .gwt-cache folder generated during hosted mode runs and GWT compiles is deleted. I'm not positive that this is what's causing this particular problem, but it could be that some meta info stored in the .gwt-cache directory is misinforming hosted mode that the new <md5>.gwt.rpc file isn't available.

Let us know if that works!
-Sumit Chandel

[Sumit Chandel]

Good catch, Ian!

I've cc'ed Joel to see if he can shed some more light on why this change occurred. The only reason I could think of that would make the removal of onHistoryChanged from the History class a good thing is the fact that it seems like it wouldn't make too much sense to fire history listeners without writing a history token, but I guess there's no reason to take away flexibility that was always there for that one-off case where this ability is actually useful.

In any case, we should definitely add the method removal to the release notes if this change sticks.

Cheers,
-Sumit Chandel

[Sumit Chandel]

Hi Patrick,

One thing you could try is compiling your application using the -style PRETTY flag. That should produce readable JavaScript code that you can debug in, say, FireBug if your application is breaking in Firefox (sub-in whichever other developer extension / plug-in for the browser which your application is breaking). If you can narrow the problem down to the bits of generated JavaScript that are causing the problem, please feel free to post back here or start a new thread with the details.

Hope that helps,
-Sumit Chandel

[Martin]

Sumit, thanks for the hint, but I had removed .gwt-cache yet before
without any success. Miguel has mailed me wether I am using -noserver
for testing which I really am. So maybe he has some clues to help me.
I am still waiting for his reply and for the solution. Thanks.

[Joel Webber]

This was actually there by accident originally (for ancient and now irrelevant historical reasons), and we decided (perhaps overzealously) to remove it, because it was difficult to fathom what purpose it would be used for. How exactly were you using it?

[Ian Bambury]

Hi Joel,

 

I was using it like this:

 

When history changes (due to the user pressing a browser button) the onHistoryChange fires and I set up state for the app. That's fine.

 

If someone follows a bookmark to my site (say http://examples.roughian.com/#Panels~Frame) then I need to set up that particular configuration for them, so the last thing I do when creating the site is

 

History.onHistoryChanged(History.getToken());

 

You can't do a newItem() because the history item is already set, doesn't change and therefore doesn't fire the onChange event.

 

That's why I noticed it.

 

Luckily, all my menus cascade, so the main widget passes the rest of the token to the Panel widget which then displays the Frame page, but there could be situations where there are a number of history listeners responding to different sections of the token.

 

But as a more general rule, is it a good idea to remove something (especially without consulting the users or even documenting the change when you release it) just because *you* can't think of a way to use it? The GWT team did with setStyleName etc when 1.4 came out and had to backtrack because you couldn't think of any reason why users might want to remove a style after they had added it.

 

You are producing a (damn fine) framework, but just because something isn't useful to you when creating a framework, it doesn't mean that it isn't useful when *using* a framework.

 

And you'll never guess all the ways people use what you provide. I'm currently using a DVD as a drinks coaster, and a hard disk as a paperweight.

 

Ian

 

2008/8/14 Joel Webber <j...@google.com>

[Joel Webber]

I do see your point, although I should point out that the setStyleName() fiasco was an attempt to reconcile two API's that couldn't safely coexist with one-another (i.e. setStyleName() really just blows away everything done by the others, and vice versa -- but we just had to give up on protecting people from that situation). In this case, History.onHistoryChanged() was a complete accident -- though I see how it could be useful.

@scottb, jat: When we decided to pull this out, I think we probably overstepped a bit. Would either of you object to putting it back?

[John Tamplin]

On Thu, Aug 14, 2008 at 11:31 AM, Joel Webber <j...@google.com> wrote:

@scottb, jat: When we decided to pull this out, I think we probably overstepped a bit. Would either of you object to putting it back?

In the previous implementation, things would get confused if you called it in certain scenarios on certain browsers.  I think the way it is currently implemented, it should always be safe to call HistoryImpl.fireHistoryChanged to just trigger the handlers.  One question that remains is should that set the current token or not (both GWT's idea of it and the URL, or just one of them) -- otherwise it seems like you could get anomalous behavior, but it seems like we would need to do lots of testing to make sure things still worked properly across all platforms.

I am not opposed to adding the functionality, just saying that I don't think it is a trivial addition.  Also, I don't really like the name -- it seems like it should be fireOnHistoryChanged or similar.

--
John A. Tamplin
Software Engineer (GWT), Google

[Scott Blum]

Q: What is the "right" way to make sure the initial history token takes effect without necessarily writing additional code?

I think the answer to that question determines the right course of action.  Adding it back, deprecating it, and documenting the appropriate solution might be one good solution.

On Thu, Aug 14, 2008 at 11:31 AM, Joel Webber <j...@google.com> wrote:

[Patrick Julien]

It was a pain but yes, that's what I did, issue #2742 was logged.

--
http://www.spectrumdt.com
http://codepimps.org

[Scott Blum]

Here's another idea:

What if, at the moment you add a history listener, that listener gets a synchronous callback with the current history token?  Wouldn't that "do the right thing" in almost every case and remove the former need for onHistoryChanged to get the first event?  I'm guessing a significant number of history-based GWT apps navigate back/forward correctly but fail the bookmark test due to not processing the initial token; this would most likely fix them.

Meanwhile, apps that are handling it correctly would get a compile error against onHistoryChanged.  I guess the missing piece in this scheme would be a way to tell those developers that it's not needed any longer?

Either way, this definitely will need a release-notes callout.

[Isaac Truett]

That'll still mess with apps like mine which call onHistoryChanged on
the *listener* to initialize state. I'll get a double dose. Just
something to be aware of. And it wouldn't hurt to have an
addHistoryListener(HistoryListener listener, boolean initialize) to
specifically request that I *not* receive the current token in case
I'm messing with listeners in the normal course of operations.

[fr...@allen-sauer.com]

+1

This is exactly the case I have to specifically code for (initial
token), and the implementation I had to change when this method got
dropped.

(I realize there may be code out there that would break under this
proposal, but I agree that getting the initial token case to "just
work" is important)

Fred

--
Fred Sauer
fr...@allen-sauer.com

[Scott Blum]

On Thu, Aug 14, 2008 at 2:55 PM, Isaac Truett <itr...@gmail.com> wrote:

That'll still mess with apps like mine which call onHistoryChanged on
the *listener* to initialize state. I'll get a double dose. Just
something to be aware of. And it wouldn't hurt to have an
addHistoryListener(HistoryListener listener, boolean initialize) to
specifically request that I *not* receive the current token in case
I'm messing with listeners in the normal course of operations.

Good points.  Let me take another stab at this then...

1) We add History.fireCurrentHistoryState() or something like it; the recommended  way to ensure all your listeners get the initial state token at the end of onModuleLoad.

2) We deprecate onHistoryChanged() but leave it in to avoid breaking; it simply fires the provided token to all attached listeners with no internal state change.  The deprecation doc suggests fireCurrentHistoryState().

3) Maybe, we add the addHistoryListener(HistoryListener listener, boolean fireCurrentHistoryState), which does what you might imagine, and leave the existing addHistoryListener alone.

Thoughts?

[Isaac Truett]

Sounds good to me.

[Ian Bambury]

What I want (what I had) is a way to fire the listeners with the current history token.

 

Being able to call them with a different token but not have a history item written was useful, too (i.e. I can put the app in a state which I don't want in the history stack) but that is not strictly history, is it?

 

So if we're not going to get onHistoryChanged() back, I expect I'll end up rolling my own AppStateChangeListener and call that from a single history listener.

 

But 1) would be halfway between 1.5.1 and what all the other versions had. Which is less of a backward step from my point of view.

 

If you are gong to change it then 2) doesn't matter.

 

3) seems no use whatsoever since it means you have to keep track of the order you add history listeners so you can make the last one fire with the 'true' option. and you may not alway know.

 

Ian 
 

[Isaac Truett]

3) This suggestion was in response to the idea that
addHistoryListener() would automatically call
listener.onHistoryChanged() with the current token. I intended that
the boolean would enable/disable this initialization, not fire changes
to all registered listeners.

My reading of Scott's Three Point Plan was that we wouldn't lose
anything: History.onHistoryChanged() is deprecated, but still there;
History.fireCurrentHistoryState() is added to fire changes to all
registered listeners; addHistoryListener(HistoryListener listener,
boolean fireCurrentHistoryState) is added to allow one-step addition
and initialization of listeners.

(Does this topic deserve it's own thread?)

[Ian Bambury]

OK, it's not actually removed, it would be deprecated, flag a warning and the documentation would tell you to use something else.

 

All I want to do is fire the listeners preferably with a token of my choosing. From 1.0 to 1.5.0, it was possible to do that. It's no big deal if it's effectively taken away from mainstream use, but no-one has really explained what's wrong with it.

 

Joel says: [removing] History.onHistoryChanged() was a complete accident

 

John Tamplin says: In the previous implementation, things would get confused if you called it in certain scenarios on certain browsers.

without explaining what they are, or if the problems continue - but also says: I think the way it is currently implemented, it should always be safe to call HistoryImpl.fireHistoryChanged to just trigger the handlers.
 

Scott suggests firing a listener when you add it, which means it runs when the history hasn't changed which would screw some people up, surely? And then suggests History.fireCurrentHistoryState()  which is what I thought we had, but without the flexibility of being able to specify a token.

 

It's all rather confusing to a simple soul like me. If we can have History.fireCurrentHistoryState(),  why can't we have History.fireHistoryState() and  History.fireHistoryState(String historyToken).

 

We could then rename it History.onHistoryChanged() and I'd have what I thought I had anyway. :-)

 

Ian

 

 

2008/8/14 Isaac Truett <itr...@gmail.com>

[Ed]

I just upgraded from 1.4.61 to 1.5.1 and now my GWT.create() for a
serializer has stopped working (see truncated code below). Would
appreciate any hints.

import com.google.gwt.core.client.GWT;
import com.google.gwt.json.client.JSONParser;
import com.google.gwt.json.client.JSONValue;
import com.google.gwt.http.client.Request;
import com.google.gwt.http.client.RequestBuilder;
import com.google.gwt.http.client.RequestCallback;
import com.google.gwt.http.client.RequestException;
import com.google.gwt.http.client.Response;

import com.gwtapps.serialization.client.JSONDocument;
import com.gwtapps.serialization.client.DocumentAdapter;
import com.gwtapps.serialization.client.DocumentObject;
import com.gwtapps.serialization.client.Serializer;

public abstract class AbstractHTTPObjectFactory implements
ObjectFactory
{

private final Serializer serializer =
GWT.create( Serializer.class );
...
...


[ERROR] Errors in 'transient source for
com.gwtapps.serialization.client.Serializer_TypeSerializer'
[ERROR] Line 93: The constructor InvocationException() is undefined
[ERROR] Line 129: The constructor Double() is undefined
...
...
...

[Alex Epshteyn]

The posted windows ZIP file doesn't work. I've tried downloading it
multiple times from various browsers but can't open the file in
WinZip. Looks like it's corrupted. Could someone post a new file or
suggest a workaround?

Thanks,
Alex

> > -- Bruce, on behalf of the GWT team- Hide quoted text -
>
> - Show quoted text -

[Alex Epshteyn]

Two minor complaints about this release (I'm running the r1.5 branch I
built yesterday).

1) I got a warning about a final field not being serialized - this is
wrong: final fields *should* be serialized unless they are static (or
initialized to a literal).

Example:

class MyDTO {
final long timestamp = System.currentTimeMillis();
}

If I send this object from client to server, how is the server going
to know what the timestamp was on the client unless the field is
serialized?


2) EmbeddedTomcatServer:289 - logic has been added to overwrite an
existing web.xml

I actually use the embedded tomcat in hosted mode (it's much more
convenient than -noserver) and I provide my own web.xml - with this
new change I have to "touch" my web.xml every time I upgrade to a new
build of GWT. Minor nuisance, but somewhat annoying. However the
biggest problem is that I wasted half an hour trying to figure out
what's going on, and I imagine other developers might when they go
from GWT 1.4 to 1.5


Alex

On Aug 19, 2:48 pm, Alex Epshteyn <alexander.epsht...@gmail.com>
wrote:

> > - Show quoted text -- Hide quoted text -

[Chris Quirk]

When will the accompanying jars be posted to the google maven repo?
Thanks.