[gwt-contrib] Re: Delivery Status Notification (Failure)
On Thu, Nov 22, 2012 at 4:22 PM, John A. Tamplin j...@jaet.org wrote: It should be the case that if you ever see server code referencing client classes it is an error, and if we leave things like this around then we won't ever get away from it. Another place where server code (shared code actually) references client code is I18N: at least c.g.g.i18n.shared.Bidi* classes reference c.g.g.i18n.client.LocaleInfo and HasDirection.Direction; there might be others. Have the Bidi* classes mistakenly been put in shared instead of client, or was the client → shared move incomplete, or should the Bidi* classes have been split in shared vs. client APIs? I currently have no idea how/where to split I18N into client/shared/server JARs. -- Thomas Broyer /tɔ.ma.bʁwa.je/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Delivery Status Notification (Failure)
On Thu, Nov 22, 2012 at 3:43 PM, Thomas Broyer t.bro...@gmail.com wrote: The only problem with this is that, without a (deprecated) indirection, you'd be forced to wait that all your 3rd-party dependencies (that depend on the renamed classes) update to the new version of GWT before you can update too. Exactly, which is why in the past we tried to overlap the old deprecated API and the new one so libraries could transition. Otherwise, you force everyone to upgrade everything in lock-step, which can be really painful. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Delivery Status Notification (Failure)
On Thu, Nov 22, 2012 at 3:17 PM, John A. Tamplin j...@jaet.org wrote: Apparently I don't have post access to gwt-steering. Yes, the group readable by everyone but only writable by the Steering Committee members (this was the intended settings but they apparently were setup wrong in the early days, so others have been able to post previously). Because you're going technical, you might send your reply to gwt-contrib instead. And because it's about an issue, you could also have added a comment on the issue itself ;-) (granted, I could have Cc'd gwt-contrib too) Following up to gwt-contrib then, and Cc'ing gwt-steering to somehow notify the SC members. 1. CRITICAL: java.lang.NoClassDefFoundError: com/google/gwt/core/client/GWTBridge https://code.google.com/p/google-web-toolkit/issues/detail?id=7527 Regarding the server calling client issue -- is it correct that the client code is actually forked via super-source so that it works properly on client or server? I believe so yes. Not sure all those classes have super-sources but I don't think it's a problem either. If so, maybe we should rename it to shared, That'd be a breaking change. These are mostly internals, but I bet at least a few people are using c.g.g.user.client.rpc.core.* classes in their own custom field serializers, so I guess it's too late for a rename (and I'm not in the mood to introduce an indirection where all (deprecated) *.client.* classes would just delegate to their *.shared.* counterparts). and yes it definitely should use the shared GWT class. -- Thomas Broyer /tɔ.ma.bʁwa.je/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Delivery Status Notification (Failure)
On Thu, Nov 22, 2012 at 9:41 AM, Thomas Broyer t.bro...@gmail.com wrote: 1. CRITICAL: java.lang.NoClassDefFoundError: com/google/gwt/core/client/GWTBridge https://code.google.com/p/google-web-toolkit/issues/detail?id=7527 Regarding the server calling client issue -- is it correct that the client code is actually forked via super-source so that it works properly on client or server? I believe so yes. Not sure all those classes have super-sources but I don't think it's a problem either. If so, maybe we should rename it to shared, That'd be a breaking change. These are mostly internals, but I bet at least a few people are using c.g.g.user.client.rpc.core.* classes in their own custom field serializers, so I guess it's too late for a rename (and I'm not in the mood to introduce an indirection where all (deprecated) *.client.* classes would just delegate to their *.shared.* counterparts). It doesn't seem that hard to add the redirection (and it should impose only minimal overhead in those cases, just the class ids), and it avoids indefinitely using *.client.* code on the server. It should be the case that if you ever see server code referencing client classes it is an error, and if we leave things like this around then we won't ever get away from it. Also, regarding breaking changes, what exactly is the criteria for what is acceptable? You have an outstanding change that would break any code that previously passed a Target to something accepting HasText, so I'm not sure I know what level of breaking change is acceptable and what benefit is required. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Delivery Status Notification (Failure)
On Thu, Nov 22, 2012 at 4:22 PM, John A. Tamplin j...@jaet.org wrote: On Thu, Nov 22, 2012 at 9:41 AM, Thomas Broyer t.bro...@gmail.com wrote: 1. CRITICAL: java.lang.NoClassDefFoundError: com/google/gwt/core/client/GWTBridge https://code.google.com/p/google-web-toolkit/issues/detail?id=7527 Regarding the server calling client issue -- is it correct that the client code is actually forked via super-source so that it works properly on client or server? I believe so yes. Not sure all those classes have super-sources but I don't think it's a problem either. If so, maybe we should rename it to shared, That'd be a breaking change. These are mostly internals, but I bet at least a few people are using c.g.g.user.client.rpc.core.* classes in their own custom field serializers, so I guess it's too late for a rename (and I'm not in the mood to introduce an indirection where all (deprecated) *.client.* classes would just delegate to their *.shared.* counterparts). It doesn't seem that hard to add the redirection (and it should impose only minimal overhead in those cases, just the class ids), and it avoids indefinitely using *.client.* code on the server. It should be the case that if you ever see server code referencing client classes it is an error, and if we leave things like this around then we won't ever get away from it. The RemoteService interface might be more problematic, but still doable I guess (you made the change with many I18N interfaces). Note that I didn't say it would be hard to add the indirection, only that if I'm the one making the client.GWT → shared.GWT change (as I proposed to do), I'll do just that for the 2.5.1 timeframe. I wholeheartedly agree the client → shared renaming is something to put on the roadmap though. Also, regarding breaking changes, what exactly is the criteria for what is acceptable? You have an outstanding change that would break any code that previously passed a Target to something accepting HasText, so I'm not sure I know what level of breaking change is acceptable and what benefit is required. Ha, good call. Ideally, I think the HasText interface would be pulled in a module of its own that I18N could inherit. With a bit of bad faith, I could argue that AutoDirectionHandler is newer than GWT-RPC so the chances of breaking someone's code are lower (it's still 2 years old though), I also believe it's much less widely used than GWT-RPC (particularly the case of passing a Target to something accepting a HasText), but of course you're right. As a side note, I introduced another breaking change in JSONP, widening the return type of getCallback: https://gwt-review.googlesource.com/#/c/1230/2/user/src/com/google/gwt/jsonp/client/JsonpRequest.java Maybe the solution here would be to extract AsyncCallback in a module of its own too. -- Thomas Broyer /tɔ.ma.bʁwa.je/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Delivery Status Notification (Failure)
The steering group should clearly define what breaking changes are allowed and which one would require a deprecation phase. GWT is a growing framework and if it contains clearly wrong internal dependencies of classes this should be fixed. I would guess it would simplify the build process (and mavenization) and you don't risk to make the dependency situation more complex than it should be. If its only renaming a package from X to Y then, as a developer, I am totally fine if my code becomes broken after updating GWT because I could fix that via some IDE automatism like organize imports or a global search/replace on import statements. As long as its well documented in the release notes, so it does not hit me like a surprise, this should be fine. -- J. Am Donnerstag, 22. November 2012 17:03:22 UTC+1 schrieb Thomas Broyer: On Thu, Nov 22, 2012 at 4:22 PM, John A. Tamplin j...@jaet.orgjavascript: wrote: On Thu, Nov 22, 2012 at 9:41 AM, Thomas Broyer t.br...@gmail.comjavascript: wrote: 1. CRITICAL: java.lang.NoClassDefFoundError: com/google/gwt/core/client/GWTBridge https://code.google.com/p/google-web-toolkit/issues/detail?id=7527 Regarding the server calling client issue -- is it correct that the client code is actually forked via super-source so that it works properly on client or server? I believe so yes. Not sure all those classes have super-sources but I don't think it's a problem either. If so, maybe we should rename it to shared, That'd be a breaking change. These are mostly internals, but I bet at least a few people are using c.g.g.user.client.rpc.core.* classes in their own custom field serializers, so I guess it's too late for a rename (and I'm not in the mood to introduce an indirection where all (deprecated) *.client.* classes would just delegate to their *.shared.* counterparts). It doesn't seem that hard to add the redirection (and it should impose only minimal overhead in those cases, just the class ids), and it avoids indefinitely using *.client.* code on the server. It should be the case that if you ever see server code referencing client classes it is an error, and if we leave things like this around then we won't ever get away from it. The RemoteService interface might be more problematic, but still doable I guess (you made the change with many I18N interfaces). Note that I didn't say it would be hard to add the indirection, only that if I'm the one making the client.GWT → shared.GWT change (as I proposed to do), I'll do just that for the 2.5.1 timeframe. I wholeheartedly agree the client → shared renaming is something to put on the roadmap though. Also, regarding breaking changes, what exactly is the criteria for what is acceptable? You have an outstanding change that would break any code that previously passed a Target to something accepting HasText, so I'm not sure I know what level of breaking change is acceptable and what benefit is required. Ha, good call. Ideally, I think the HasText interface would be pulled in a module of its own that I18N could inherit. With a bit of bad faith, I could argue that AutoDirectionHandler is newer than GWT-RPC so the chances of breaking someone's code are lower (it's still 2 years old though), I also believe it's much less widely used than GWT-RPC (particularly the case of passing a Target to something accepting a HasText), but of course you're right. As a side note, I introduced another breaking change in JSONP, widening the return type of getCallback: https://gwt-review.googlesource.com/#/c/1230/2/user/src/com/google/gwt/jsonp/client/JsonpRequest.java Maybe the solution here would be to extract AsyncCallback in a module of its own too. -- Thomas Broyer /tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Delivery Status Notification (Failure)
On Thursday, November 22, 2012 6:16:54 PM UTC+1, Jens wrote: The steering group should clearly define what breaking changes are allowed and which one would require a deprecation phase. Agreed, we also need to define the duration of the deprecation phase (this is something I already put on the table, but we had other things to talk about at that time) GWT is a growing framework and if it contains clearly wrong internal dependencies of classes this should be fixed. I would guess it would simplify the build process (and mavenization) and you don't risk to make the dependency situation more complex than it should be. If its only renaming a package from X to Y then, as a developer, I am totally fine if my code becomes broken after updating GWT because I could fix that via some IDE automatism like organize imports or a global search/replace on import statements. As long as its well documented in the release notes, so it does not hit me like a surprise, this should be fine. -- J. Am Donnerstag, 22. November 2012 17:03:22 UTC+1 schrieb Thomas Broyer: On Thu, Nov 22, 2012 at 4:22 PM, John A. Tamplin j...@jaet.org wrote: On Thu, Nov 22, 2012 at 9:41 AM, Thomas Broyer t.br...@gmail.com wrote: 1. CRITICAL: java.lang.NoClassDefFoundError: com/google/gwt/core/client/GWTBridge https://code.google.com/p/google-web-toolkit/issues/detail?id=7527 Regarding the server calling client issue -- is it correct that the client code is actually forked via super-source so that it works properly on client or server? I believe so yes. Not sure all those classes have super-sources but I don't think it's a problem either. If so, maybe we should rename it to shared, That'd be a breaking change. These are mostly internals, but I bet at least a few people are using c.g.g.user.client.rpc.core.* classes in their own custom field serializers, so I guess it's too late for a rename (and I'm not in the mood to introduce an indirection where all (deprecated) *.client.* classes would just delegate to their *.shared.* counterparts). It doesn't seem that hard to add the redirection (and it should impose only minimal overhead in those cases, just the class ids), and it avoids indefinitely using *.client.* code on the server. It should be the case that if you ever see server code referencing client classes it is an error, and if we leave things like this around then we won't ever get away from it. The RemoteService interface might be more problematic, but still doable I guess (you made the change with many I18N interfaces). Note that I didn't say it would be hard to add the indirection, only that if I'm the one making the client.GWT → shared.GWT change (as I proposed to do), I'll do just that for the 2.5.1 timeframe. I wholeheartedly agree the client → shared renaming is something to put on the roadmap though. Also, regarding breaking changes, what exactly is the criteria for what is acceptable? You have an outstanding change that would break any code that previously passed a Target to something accepting HasText, so I'm not sure I know what level of breaking change is acceptable and what benefit is required. Ha, good call. Ideally, I think the HasText interface would be pulled in a module of its own that I18N could inherit. With a bit of bad faith, I could argue that AutoDirectionHandler is newer than GWT-RPC so the chances of breaking someone's code are lower (it's still 2 years old though), I also believe it's much less widely used than GWT-RPC (particularly the case of passing a Target to something accepting a HasText), but of course you're right. As a side note, I introduced another breaking change in JSONP, widening the return type of getCallback: https://gwt-review.googlesource.com/#/c/1230/2/user/src/com/google/gwt/jsonp/client/JsonpRequest.java Maybe the solution here would be to extract AsyncCallback in a module of its own too. -- Thomas Broyer /tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Delivery Status Notification (Failure)
On Thu, Nov 22, 2012 at 11:02 AM, Thomas Broyer t.bro...@gmail.com wrote: I wholeheartedly agree the client → shared renaming is something to put on the roadmap though. Ok. Also, regarding breaking changes, what exactly is the criteria for what is acceptable? You have an outstanding change that would break any code that previously passed a Target to something accepting HasText, so I'm not sure I know what level of breaking change is acceptable and what benefit is required. Ha, good call. Ideally, I think the HasText interface would be pulled in a module of its own that I18N could inherit. Actually, trivial interfaces like HasText should just be part of core right? It isn't like they pull in other dependencies, and breaking them out into their own module seems excessive. As a side note, I introduced another breaking change in JSONP, widening the return type of getCallback: https://gwt-review.googlesource.com/#/c/1230/2/user/src/com/google/gwt/jsonp/client/JsonpRequest.java Maybe the solution here would be to extract AsyncCallback in a module of its own too. An approach we have taken elsewhere is to introduce a new method returning Callback, and the existing one (which gets deprecated) casts to AsyncCallback, letting a CCE happen if it isn't of the proper type. Granted, it clutters up the API, but it offers a way to keep from breaking any existing code (which has to be passing an AsyncCallback) while letting new code get written that is fully type-safe. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Delivery Status Notification (Failure)
Le 22 nov. 2012 19:23, John A. Tamplin j...@jaet.org a écrit : On Thu, Nov 22, 2012 at 11:02 AM, Thomas Broyer t.bro...@gmail.com wrote: Ideally, I think the HasText interface would be pulled in a module of its own that I18N could inherit. Actually, trivial interfaces like HasText should just be part of core right? It isn't like they pull in other dependencies, and breaking them out into their own module seems excessive. I meant GWT modules, which would be necessary to pull the classes apart (and slice c.g.g.u.client.ui just like I sliced c.g.g.u.client already with Cookies, Random, Timer, etc.) As for the jar (Maven module), I'd be tempted to put HasText in i18n, AsyncCallback in core, and possibly TakesValue in editor. As a side note, I introduced another breaking change in JSONP, widening the return type of getCallback: https://gwt-review.googlesource.com/#/c/1230/2/user/src/com/google/gwt/jsonp/client/JsonpRequest.java Maybe the solution here would be to extract AsyncCallback in a module of its own too. An approach we have taken elsewhere is to introduce a new method returning Callback, and the existing one (which gets deprecated) casts to AsyncCallback, letting a CCE happen if it isn't of the proper type. Granted, it clutters up the API, but it offers a way to keep from breaking any existing code (which has to be passing an AsyncCallback) while letting new code get written that is fully type-safe. It worked great in SuggestBox because we had getTextBox and wanted to change to ValueBox, so getValueBox was easy to add. Here we have getCallback returning an AsyncCallback and would possibly want to change to Callback, I can't come with a meaningful name. I think it's easier to keep AsyncCallback and simply put it in a jar that both RPC and JSONP depend on (e.g. core) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Delivery Status Notification (Failure)
On Thursday, November 22, 2012 9:13:25 PM UTC+1, Paul Robinson wrote: On 22/11/12 17:16, Jens wrote: If its only renaming a package from X to Y then, as a developer, I am totally fine if my code becomes broken after updating GWT because I could fix that via some IDE automatism like organize imports or a global search/replace on import statements. As long as its well documented in the release notes, so it does not hit me like a surprise, this should be fine. +1 The only problem with this is that, without a (deprecated) indirection, you'd be forced to wait that all your 3rd-party dependencies (that depend on the renamed classes) update to the new version of GWT before you can update too. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: Delivery Status Notification (Failure)
I extended AbstractStandardDispatchServlet in order to use it with spring
and it seems that getDispatch() from here returns me null Dispatch Object.
package cayetano.common.web.handler;
import javax.inject.Inject;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import net.customware.gwt.dispatch.server.Dispatch;
import
net.customware.gwt.dispatch.server.standard.AbstractStandardDispatchServlet;
import org.springframework.beans.factory.config.AutowireCapableBeanFactory;
import org.springframework.web.context.WebApplicationContext;
import org.springframework.web.context.support.WebApplicationContextUtils;
public final class StandardDispatchServiceServlet extends
AbstractStandardDispatchServlet {
private static final long serialVersionUID = 1L;
private Dispatch dispatch;
@Override
public void init(ServletConfig config) throws ServletException {
super.init(config);
WebApplicationContext ctx =
WebApplicationContextUtils.getRequiredWebApplicationContext(config.getServletContext());
AutowireCapableBeanFactory beanFactory =
ctx.getAutowireCapableBeanFactory();
beanFactory.autowireBean(this);
}
@Inject
public void setDispatch(Dispatch dispatch) {
this.dispatch = dispatch;
}
@Override
protected Dispatch getDispatch() {
return dispatch;
}
}
On Tue, May 10, 2011 at 3:35 PM, Mail Delivery Subsystem
mailer-dae...@google.com wrote:
Hello nenchev.mari...@gmail.com,
We're writing to let you know that the group you tried to contact
(gwt-dispatch) may not exist, or you may not have permission to post
messages to the group. A few more details on why you weren't able to post:
* You might have spelled or formatted the group name incorrectly.
* The owner of the group may have removed this group.
* You may need to join the group before receiving permission to post.
* This group may not be open to posting.
If you have questions related to this or any other Google Group, visit the
Help Center at http://groups.google.com/support/?hl=en_US.
Thanks,
Google Groups
- Original message -
Received: by 10.227.6.201 with SMTP id a9mr499687wba.9.1305030944722;
Tue, 10 May 2011 05:35:44 -0700 (PDT)
Received: by 10.227.6.201 with SMTP id a9mr499686wba.9.1305030944699;
Tue, 10 May 2011 05:35:44 -0700 (PDT)
Return-Path: nenchev.mari...@gmail.com
Received: from mail-ww0-f52.google.com (mail-ww0-f52.google.com[74.125.82.52])
by gmr-mx.google.com with ESMTPS id
15si2056852wbl.0.2011.05.10.05.35.44
(version=TLSv1/SSLv3 cipher=OTHER);
Tue, 10 May 2011 05:35:44 -0700 (PDT)
Received-SPF: pass (google.com: domain of nenchev.mariyan@gmail.comdesignates
74.125.82.52 as permitted sender) client-ip=74.125.82.52;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of
nenchev.mari...@gmail.com designates 74.125.82.52 as permitted sender)
smtp.mail=nenchev.mari...@gmail.com; dkim=pass (test mode) header.i=@
gmail.com
Received: by mail-ww0-f52.google.com with SMTP id 31so2227465wwb.33
for multiple recipients; Tue, 10 May 2011 05:35:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:date:message-id:subject:from:to
:content-type;
bh=m20dryqixWN7v5wibo2n0TSMDH8u7b5FNvrDtRbfXys=;
b=gVPVm0JVv7h8npgCDmsk1JB1hVcIoGNf3IJC4GQrUwjsm0OtA5FWOF+OoL5ZJ0HciB
mVAqE24y8qNbqdQEGF0HvgmkFh1bvEBSTjhAygD7qCvEgQt/wrxKQsXnDMaOcoaCa95u
Z+CCHQlKI+YNPmcox3z36FkwGEizDqOJjKQBo=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:date:message-id:subject:from:to:content-type;
b=u11xJ05YpJuyd0NNYBt1jxo8aP//WMIdWjGYcJ8SnilZPfFcOEvpXpB/5f84vqjwaq
yQx0GVvEMxug0TPJ99bYj/8UepqOvNtp3muYrGlEChZFiUwZgKi2mbNRz8575oCVGTGU
b/g7oEJXW6LQarNKUgj1WesOH4T8yi0isxCV8=
MIME-Version: 1.0
Received: by 10.227.172.143 with SMTP id l15mr928739wbz.80.1305030944539;
Tue,
10 May 2011 05:35:44 -0700 (PDT)
Received: by 10.227.148.17 with HTTP; Tue, 10 May 2011 05:35:44 -0700 (PDT)
Date: Tue, 10 May 2011 15:35:44 +0300
Message-ID: BANLkTi=ypktqupporwn3mv8ksvfsppy...@mail.gmail.com
Subject: Strange NullPointerException during getDispatch().execute(action);
From: mariyan nenchev nenchev.mari...@gmail.com
To: gwt-dispa...@googlegroups.com,
Google Web Toolkit Google-Web-Toolkit@googlegroups.com
Content-Type: multipart/alternative; boundary=485b3973f087dec5ad04a2eb31b3
Hi
I am getting very strange exception during execution of dispatch action. It
seems that getDispatch() returns null?! Here is the exception:
rpcDispatcher: Exception while executing
cayetano.games.updownbet.web.shared.handler.action.UpDownBetGameAction:
null
java.lang.NullPointerException
at
net.customware.gwt.dispatch.server.standard.AbstractStandardDispatchServlet.execute(AbstractStandardDispatchServlet.java:17)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
Re: Delivery Status Notification (Failure)
Hi all Sorry for this simple question because I am New in GWT. I get problem in UIBnder with ListBox. I hava a Class *Base *and I defined variable *name* in it. I hava a list for this name and I want to choose one of It. So I use @UiField ListBox name; and in ui.xml file I use g:ListBox styleName=txtbx ui:field=name visibleItemCount='1' name = name /g:ListBox but when I run this It shows error 10:01:09.668 [ERROR] [applicationScaffold] The UiField com.google.gwt.user.client.ui.ListBox name does not have a HaxText or HasValue super-interface Plz help me on this topic. -- With Thanks Regards Kuldeep Poonia -- With Thanks Regards Kuldeep Poonia -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
