Re: [gwt-contrib] 2.1.1 fails in SimpleRequestProcessor.processInvocationMessages when no Invokations
On the client I am effectively doing the following (I've removed the widget
stuff for ease of reading):
interface Driver extends RequestFactoryEditorDriver {}
...
driver.initialize(clientFactory.getEventBus(),
clientFactory.getRequestFactory(),
editArticleView.getEditor());
driver.edit(articleProxy, clientFactory
.getRequestFactory().articleRequest());
driver.flush().fire(new Receiver() {...});
...
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] 2.1.1 fails in SimpleRequestProcessor.processInvocationMessages when no Invokations
On Tue, Dec 21, 2010 at 7:24 PM, Cory wrote: > (cross posted from users list as this is most likely more relevant to this > list, being a possible bug) What sequence of client-side API calls did you make in order to get a payload with no invocations? -- Bob Vawter Google Web Toolkit Team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] 2.1.1 fails in SimpleRequestProcessor.processInvocationMessages when no Invokations
Hi,
(cross posted from users list as this is most likely more relevant to this
list, being a possible bug)
I believe I've uncovered an error in version 2.1.1 of SimpleRequestProcessor
when there are no invocations and only operations in a RequestMessage from
the client (stacktrace at end of email).
I'm checking here before creating an issue.
I am using an editor on the client to modify a property, then flushing and
firing.
So the RequestMessage from the client is:
---
{Operations=[{PropertyMap={title=150349-0 Title CHANGED},
ServerId=IjY1Zjg4ZjVlLWFlNDItNDcxYi04NGNkLWE2MWJmOGUxNzBjZCI=,
Operation=UPDATE, Version=MQ==,
TypeToken=au.projectx.gwt.request.ArticleProxy}]}
---
With the following stacktrace:
---
[#|2010-12-21T15:05:48.626+1100|SEVERE|glassfish3.0.1|com.google.gwt.requestfactory.server.RequestFactoryServlet|_ThreadID=28;_ThreadName=Thread-1;|Unexpected
error
java.lang.NullPointerException
at
com.google.gwt.requestfactory.server.SimpleRequestProcessor.processInvocationMessages(SimpleRequestProcessor.java:414)
at
com.google.gwt.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:218)
at
com.google.gwt.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java:125)
at
com.google.gwt.requestfactory.server.RequestFactoryServlet.doPost(RequestFactoryServlet.java:118)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
---
It seems to me that either
SimpleRequestProcessor.processInvocationMessages() needs to cater for a null
List or RequestMessage.getInvocations() should return an
empty list instead of a null.
-- Cory
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RequestFactory entity proxies can't be cloned
On Mon, Dec 20, 2010 at 3:10 PM, Matt Moriarity wrote: > I'm attempting to switch to using RequestFactory instead of GWT-RPC and > manually creating DTOs. It's been going pretty well, except I've hit one > use-case that is just a brick wall. > > I have a panel that is an Editor which uses a > RequestFactoryEditorDriver to handle the editing. One of the properties of > DocumentProxy is another proxy, which I want to edit in a dialog box that > shows when a button is clicked in the panel. The dialog is another Editor. > > The problem is that anytime something changes in this dialog, I want to > flush the editor, send the current values to the server for validation, and > report any errors right away. This works fine, but the dialog box has a > cancel button, which should revert any changes made in the dialog box. > > I was able to do this before by storing the original value when it's set, > and editing a clone while in the dialog box. But entity proxies can't be > usefully cloned in any way that I currently see, so I'm at a loss as to how > to get this behavior. It only makes sense to clone an (immutable) EntityProxy that's not associated with a RequestContext. Cloning one associated with a pending request would lead to contention about which proxy has the canonical new values to send to the server. The future-proof way: The DocumentEditor can call the DetailEditor with the stableId() of the entity to edit. The DetailEditor fires its own find() request to retrieve a new EntityProxy to edit. If the DetailEditor commits a change back to the server (causing the version number of the entity to change), the DocumentEditor can use the EditorDelegate.subscribe() to receive the notification that the DetailEditor made something change on the server. In the future, RequestFactory will gain a way to cache data locally, so the cost of the redundant call can be eliminated. The slower, but no-request way: Use the ProxySerializer available from the RequestFactory to clone via client-local serialization. If the object that's being cloned has a non-trivial reference graph, this could be somewhat slow. The coloring-outside-the-lines way which will probably break in the future: Use AutoBeanUtils.getAutoBean(someEntityProxy) to retrieve the AutoBean controller for the FooProxy and call clone() on it. You'll need to copy the com.google.gwt.requestfactory.shared.impl.Constants.STABLE_ID tag from the source bean to the cloned bean and call freeze() on the cloned bean to prevent assertion failures. I don't recommend this approach since it relies on the RequestFactory plumbing not changing in the future. -- Bob Vawter Google Web Toolkit Team -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Rolling back Generator Result Caching for RPC (issues have been identified) (issue1241801)
LGTM http://gwt-code-reviews.appspot.com/1241801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Rolling back Generator Result Caching for RPC (issues have been identified) (issue1241801)
Reviewers: zundel, Description: Rolling back Generator Result Caching for RPC (issues have been identified) Please review this at http://gwt-code-reviews.appspot.com/1241801/show Affected files: M user/src/com/google/gwt/rpc/rebind/RpcProxyCreator.java M user/src/com/google/gwt/user/rebind/rpc/ProxyCreator.java M user/src/com/google/gwt/user/rebind/rpc/ServiceInterfaceProxyGenerator.java M user/src/com/google/gwt/user/rebind/rpc/TypeSerializerCreator.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Generator Result Caching implementation for ClientBundle (issue1236801)
http://gwt-code-reviews.appspot.com/1236801/diff/1/3
File user/src/com/google/gwt/resources/ext/ResourceContext.java (right):
http://gwt-code-reviews.appspot.com/1236801/diff/1/3#newcode147
user/src/com/google/gwt/resources/ext/ResourceContext.java:147: * a
given method. This data will be populated and available prior to any
On 2010/12/21 17:03:03, bobv wrote:
method, based on the presence of an {...@link Source} annotation or the
method or
the {...@link DefaultExtensions} annotation of the ResourceGenerator.
Hopefully a bit clearer now
The whole populated and available statement seems kind of a weird
thing to
guarantee here.
Is there any time where it's invalid to call this method?
http://gwt-code-reviews.appspot.com/1236801/diff/1/3#newcode170
user/src/com/google/gwt/resources/ext/ResourceContext.java:170:
On 2010/12/21 17:03:03, bobv wrote:
Whitespace.
Done.
http://gwt-code-reviews.appspot.com/1236801/diff/1/6
File
user/src/com/google/gwt/resources/rebind/context/AbstractClientBundleGenerator.java
(right):
http://gwt-code-reviews.appspot.com/1236801/diff/1/6#newcode231
user/src/com/google/gwt/resources/rebind/context/AbstractClientBundleGenerator.java:231:
On 2010/12/21 17:03:03, bobv wrote:
Whitespace, here and elsewhere.
Done.
http://gwt-code-reviews.appspot.com/1236801/diff/1/6#newcode362
user/src/com/google/gwt/resources/rebind/context/AbstractClientBundleGenerator.java:362:
return new RebindResult(RebindStatus.USE_ALL_NEW, createdClassName,
cpi);
On 2010/12/21 17:03:03, bobv wrote:
Where do the previously-emitted resource files live (e.g.
*.cache.png)? Are
they deleted between refreshes so that staleness will become glaring
obvious?
This is just reverting to the same behavior prior to the this patch,
that is, previously emitted resource files have already been overwritten
(or renamed) by the time we get here, and thus we return the status to
USE_ALL_NEW resources/artifacts. If we had bailed early above prior to
re-running the generation (and returning a status of USE_ALL_CACHED),
we'd be using the previously generated resource files in place (and not
overwritten).
http://gwt-code-reviews.appspot.com/1236801/diff/1/6#newcode438
user/src/com/google/gwt/resources/rebind/context/AbstractClientBundleGenerator.java:438:
long lastModified =
generatorContext.getSourceLastModifiedTime(sourceType);
On 2010/12/21 17:03:03, bobv wrote:
How does this handle the case where a CssResource subtype is not
necessarily
defined in the same compilation unit as the ClientBundle subtype?
Good point, I've added the method's return type (e.g. a resource type),
and it's parents, to the list of source types that need to be checked
(see below).
http://gwt-code-reviews.appspot.com/1236801/diff/1/6#newcode655
user/src/com/google/gwt/resources/rebind/context/AbstractClientBundleGenerator.java:655:
cacheable = false;
On 2010/12/21 17:03:03, bobv wrote:
Why not just return false immediately?
I've added a comment to clarify above the decl for 'cacheable', but
essentially, we need to iterate over all the methods to completion
regardless of whether cacheable becomes false, since if it is false,
then we still need to find and add all the resouces to the context, for
subsequent processing.
http://gwt-code-reviews.appspot.com/1236801/diff/1/7
File
user/src/com/google/gwt/resources/rebind/context/AbstractResourceContext.java
(right):
http://gwt-code-reviews.appspot.com/1236801/diff/1/7#newcode142
user/src/com/google/gwt/resources/rebind/context/AbstractResourceContext.java:142:
On 2010/12/21 17:03:03, bobv wrote:
Whitespace, here and elsewhere.
Done.
http://gwt-code-reviews.appspot.com/1236801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Generator Result Caching implementation for ClientBundle (issue1236801)
http://gwt-code-reviews.appspot.com/1236801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r9475 committed - Select the correct ConstraintValidator for the bean type....
Revision: 9475
Author: ncha...@google.com
Date: Tue Dec 21 06:50:31 2010
Log: Select the correct ConstraintValidator for the bean type.
This does not implement the full spec, but will always return
a compatible ConstraintValidator if available.
[JSR 303 TCK Result] 53 of 258 (20.54%) Pass with 28 Failures and 13 Errors.
Review at http://gwt-code-reviews.appspot.com/1238801
Review by: rchan...@google.com
http://code.google.com/p/google-web-toolkit/source/detail?r=9475
Added:
/trunk/samples/validationtck/test/com/google/gwt/sample/validationtck/constraints/customconstraint
/trunk/samples/validationtck/test/com/google/gwt/sample/validationtck/constraints/customconstraint/CustomConstraintGwtSuite.java
/trunk/samples/validationtck/test/com/google/gwt/sample/validationtck/constraints/customconstraint/CustomConstraintValidatorGwtTest.java
/trunk/samples/validationtck/test/com/google/gwt/sample/validationtck/constraints/customconstraint/TckTest.gwt.xml
/trunk/samples/validationtck/test/com/google/gwt/sample/validationtck/constraints/customconstraint/TckTestValidatorFactory.java
/trunk/samples/validationtck/test/org/hibernate/jsr303/tck/tests
/trunk/samples/validationtck/test/org/hibernate/jsr303/tck/tests/constraints
/trunk/samples/validationtck/test/org/hibernate/jsr303/tck/tests/constraints/validatorresolution
/trunk/samples/validationtck/test/org/hibernate/jsr303/tck/tests/constraints/validatorresolution/TckTest.gwt.xml
/trunk/samples/validationtck/test/org/hibernate/jsr303/tck/tests/constraints/validatorresolution/TckTestValidatorFactory.java
/trunk/samples/validationtck/test/org/hibernate/jsr303/tck/tests/constraints/validatorresolution/ValidatorResolutionGwtSuite.java
/trunk/samples/validationtck/test/org/hibernate/jsr303/tck/tests/constraints/validatorresolution/ValidatorResolutionGwtTest.java
/trunk/user/test/com/google/gwt/validation/rebind
/trunk/user/test/com/google/gwt/validation/rebind/GwtSpecificValidatorCreatorTest.java
Modified:
/trunk/samples/validationtck/test/com/google/gwt/sample/validationtck/validation/TckTestValidatorFactory.java
/trunk/user/src/com/google/gwt/validation/rebind/GwtSpecificValidatorCreator.java
/trunk/user/src/com/google/gwt/validation/rebind/ValidatorCreator.java
===
--- /dev/null
+++
/trunk/samples/validationtck/test/com/google/gwt/sample/validationtck/constraints/customconstraint/CustomConstraintGwtSuite.java
Tue Dec 21 06:50:31 2010
@@ -0,0 +1,32 @@
+/*
+ * Copyright 2010 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License"); you may
not
+ * use this file except in compliance with the License. You may obtain a
copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
under
+ * the License.
+ */
+package com.google.gwt.sample.validationtck.constraints.customconstraint;
+
+import com.google.gwt.junit.tools.GWTTestSuite;
+
+import junit.framework.Test;
+
+/**
+ * Tck Tests for the {...@code constraints customconstraint} package.
+ */
+public class CustomConstraintGwtSuite {
+ public static Test suite() {
+GWTTestSuite suite = new GWTTestSuite(
+"TCK for GWT Validation, constraints customconstraint package");
+suite.addTestSuite(CustomConstraintValidatorGwtTest.class);
+return suite;
+ }
+}
===
--- /dev/null
+++
/trunk/samples/validationtck/test/com/google/gwt/sample/validationtck/constraints/customconstraint/CustomConstraintValidatorGwtTest.java
Tue Dec 21 06:50:31 2010
@@ -0,0 +1,64 @@
+/*
+ * Copyright 2010 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License"); you may
not
+ * use this file except in compliance with the License. You may obtain a
copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
under
+ * the License.
+ */
+package com.google.gwt.sample.validationtck.constraints.customconstraint;
+
+import com.google.gwt.junit.client.GWTTestCase;
+
+import
org.hibernate.jsr303.tck.tests.constraints.customconstraint.CustomConstraintValidatorTest;
+
+/**
+ * Test wrapper for {...@link CustomConstraintValidatorTest}.
+ */
+public class CustomConstraintValidatorGwtTest extends GWTTestCase {
+ private final CustomConstraintValidatorTest delegate = new
CustomConstraintValidatorTest();
+
+
Re: [gwt-contrib] Re: Why does OptionalFieldEditor implements LeafValueEditor?
On Tue, Dec 21, 2010 at 12:29 PM, Thomas Broyer wrote:
> On Mon, Dec 20, 2010 at 5:58 PM, BobV wrote:
>> On Mon, Dec 20, 2010 at 11:44 AM, Thomas Broyer wrote:
>>> But how do you explain the difference in display then between
>>> OptionalFieldEditor (which also appears to work OK in DynaTableRf) and our
>>> copy without LeafValueEditor?
>>> (looks like I'll have to debug it; hopefully looking at the generated java
>>> code will tell, without resorting to debugging the generator)
>>
>> The flow through AbstractEditorDelegate.flush() is affected by whether
>> or not the editor implements LeafValueEditor. If it does, it assumes
>> that the LVE's getValue() will implicitly flush all sub-editors.
>> Similarly, the AED.refresh() method assumes that LVE's setValue() will
>> populate the sub-editors. If you remove the LeafValueEditor
>> interface, the updates would proceed through the EditorChain used by
>> the CompositeEditor interface.
>>
>> What happens when the unmodified OptionalFieldEditor.setValue() method
>> is called? It should call through the injected EditorChain with the
>> new value (just as the framework would do in the modified OFE case).
>
> Comparing the generated code between our OptionalEditor and the stock
> OptionalFieldEditor:
> 1. the delegate for the editor itself is strictly equivalent.
> 2. there is a difference in the "parent" editor though: in
> flushSubEditors, the setter for the property is called with the
> delegate's getObject() in the case of OptionalFieldEditor, but not
> with our editor (expected, given your description above).
>
> It helped me spot an issue in our code: we wanted to give access to
> some editors to the parent editor/view (a ListEditor so we could add
> an item to the list, and the optional field so we could set a value,
> in response to user actions) and exposed them as public methods that
> happens to be detected as "sub editors" by the Editor framework:
> �...@uifield IsEditor> foo;
> ...
> public OptionalFieldEditor fooEditor() { return
> foo.asEditor(); }
> This means the ListEditor and the OptionalFieldEditor are used twice,
> with 2 distinct delegates each.
> I'm not sure it would cause the issue but it sure duplicates works
> (well, given that AbstractEditorDelegate.Chain uses a map keyed on the
> editor, it might still be it).
>
> I've refactored the editor to get rid of the duplicates (I could have
> annotated the methods with @Ignore but chose to only expose the
> ListEditor#getList instead of the ListEditor itself, and the
> OptionalFieldEditor as a TakesValue) and am currently testing it.
OK, I re-tested with the modified code: it doesn't change anything.
Looking a bit more closely at the generated code though, there's a
difference in the generated FooEditor_SimpleBeanEditorDelegate: with
our optional editor, the attachSubEditors, flushSubEditors and
refreshEditors correctly calls down to the subeditors, whereas with
the OptionalFieldEditor the methods are empty (which explains why the
object is not displayed in it).
FYI, FooEditor does not implement Editor<> by itself but rather
extends an "AbstractXxxEditor implements Editor" (FooEditor
extends AbstractXxxEditor). I double-checked and the sub-editor
field for the OptionalFieldEditor is (correctly) declared as
OptionalXxxEditor (with OptionalXxxeditor being:
"class OptionalXxxEditor> extends Composite implements
IsEditor>).
Running with -log DEBUG, the generator correctly "descends into" the
ListEditor-s but not the OptionalFieldEditor.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add a warning in GWTTestCase to help users that accidentally run a GWT JUnit Test as a JUnit Test. (issue1224801)
On Tue, Dec 21, 2010 at 11:09 AM, wrote: > On 2010/12/16 19:43:39, rdayal wrote: > >> Is this system property required? >> > > This is a tough one, because I don't think it's strictly required, but > the devjar has things such as the GWT devmode bridge and the GWT > compiler. Can you think of a case where it wouldn't be set though? Let > me ask some non-GPE and non-Eclipse users to add this change and confirm > nothing breaks before asking for the LGTM. I believe if you are working with GWT instead of *on* GWT, and you aren't using GPE, gwt_devjar is not required and people would have no way of knowing they need to set it. Worse, the error message is going to be misleading for them. I think that error needs to occur only if GPE is being used, or else provide more explanation. gwt_devjar is needed primarily to find shared objects for native libraries (currently only used for Windows proxy support) and WebAppCreator needs it so it uses the right path for the generated build files (and GPE needs it because it calls WAC and I think it may set it automatically for GWT launch configs). -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r9473 committed - Fix use of length() in generated JS code....
Revision: 9473
Author: j...@google.com
Date: Tue Dec 21 05:40:19 2010
Log: Fix use of length() in generated JS code.
Patch by: jat
Review by: unnurg
http://code.google.com/p/google-web-toolkit/source/detail?r=9473
Modified:
/trunk/user/src/com/google/gwt/i18n/linker/LocalePropertyProviderGenerator.java
===
---
/trunk/user/src/com/google/gwt/i18n/linker/LocalePropertyProviderGenerator.java
Mon Dec 20 11:48:24 2010
+++
/trunk/user/src/com/google/gwt/i18n/linker/LocalePropertyProviderGenerator.java
Tue Dec 21 05:40:19 2010
@@ -192,7 +192,7 @@
body.println("var end = cookies.indexOf(';', idx);");
body.println("if (end < 0) {");
body.indent();
-body.println("end = cookies.length();");
+body.println("end = cookies.length;");
body.outdent();
body.println("}");
body.println("locale = cookies.substring(idx + " +
(cookieName.length() + 1)
@@ -257,7 +257,7 @@
body.println("var end = queryParam.indexOf(\"&\", qpStart);");
body.println("if (end < 0) {");
body.indent();
-body.println("end = queryParam.length();");
+body.println("end = queryParam.length;");
body.outdent();
body.println("}");
body.println("locale = queryParam.substring(qpStart + "
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r9472 committed - Generator Result Caching implementation for RPC...
Revision: 9472
Author: jbrosenb...@google.com
Date: Tue Dec 21 05:37:31 2010
Log: Generator Result Caching implementation for RPC
Review at http://gwt-code-reviews.appspot.com/1235801
http://code.google.com/p/google-web-toolkit/source/detail?r=9472
Modified:
/trunk/user/src/com/google/gwt/rpc/rebind/RpcProxyCreator.java
/trunk/user/src/com/google/gwt/user/rebind/rpc/ProxyCreator.java
/trunk/user/src/com/google/gwt/user/rebind/rpc/ServiceInterfaceProxyGenerator.java
/trunk/user/src/com/google/gwt/user/rebind/rpc/TypeSerializerCreator.java
===
--- /trunk/user/src/com/google/gwt/rpc/rebind/RpcProxyCreator.java Thu Dec
2 04:45:53 2010
+++ /trunk/user/src/com/google/gwt/rpc/rebind/RpcProxyCreator.java Tue Dec
21 05:37:31 2010
@@ -19,7 +19,7 @@
import com.google.gwt.core.client.impl.ArtificialRescue;
import com.google.gwt.core.client.impl.Impl;
import com.google.gwt.core.client.impl.ArtificialRescue.Rescue;
-import com.google.gwt.core.ext.GeneratorContext;
+import com.google.gwt.core.ext.GeneratorContextExt;
import com.google.gwt.core.ext.TreeLogger;
import com.google.gwt.core.ext.UnableToCompleteException;
import com.google.gwt.core.ext.typeinfo.JArrayType;
@@ -118,7 +118,7 @@
}
@Override
- protected void generateTypeHandlers(TreeLogger logger, GeneratorContext
ctx,
+ protected void generateTypeHandlers(TreeLogger logger,
GeneratorContextExt ctx,
SerializableTypeOracle serializationSto,
SerializableTypeOracle deserializationSto)
throws UnableToCompleteException {
@@ -271,7 +271,7 @@
@Override
protected String writeSerializationPolicyFile(TreeLogger logger,
- GeneratorContext ctx, SerializableTypeOracle serializationSto,
+ GeneratorContextExt ctx, SerializableTypeOracle serializationSto,
SerializableTypeOracle deserializationSto)
throws UnableToCompleteException {
===
--- /trunk/user/src/com/google/gwt/user/rebind/rpc/ProxyCreator.java Tue
Dec 14 13:56:04 2010
+++ /trunk/user/src/com/google/gwt/user/rebind/rpc/ProxyCreator.java Tue
Dec 21 05:37:31 2010
@@ -19,7 +19,7 @@
import com.google.gwt.core.client.impl.Impl;
import com.google.gwt.core.ext.BadPropertyValueException;
import com.google.gwt.core.ext.ConfigurationProperty;
-import com.google.gwt.core.ext.GeneratorContext;
+import com.google.gwt.core.ext.GeneratorContextExt;
import com.google.gwt.core.ext.PropertyOracle;
import com.google.gwt.core.ext.TreeLogger;
import com.google.gwt.core.ext.UnableToCompleteException;
@@ -248,7 +248,7 @@
*
* @throws UnableToCompleteException
*/
- public String create(TreeLogger logger, GeneratorContext context)
+ public String create(TreeLogger logger, GeneratorContextExt context)
throws UnableToCompleteException {
TypeOracle typeOracle = context.getTypeOracle();
@@ -690,7 +690,7 @@
}
protected void generateTypeHandlers(TreeLogger logger,
- GeneratorContext context, SerializableTypeOracle
typesSentFromBrowser,
+ GeneratorContextExt context, SerializableTypeOracle
typesSentFromBrowser,
SerializableTypeOracle typesSentToBrowser)
throws UnableToCompleteException {
Event event =
SpeedTracerLogger.start(CompilerEventType.GENERATOR_RPC_TYPE_SERIALIZER);
@@ -729,7 +729,7 @@
}
protected String writeSerializationPolicyFile(TreeLogger logger,
- GeneratorContext ctx, SerializableTypeOracle serializationSto,
+ GeneratorContextExt ctx, SerializableTypeOracle serializationSto,
SerializableTypeOracle deserializationSto)
throws UnableToCompleteException {
try {
@@ -830,7 +830,7 @@
}
private void emitPolicyFileArtifact(TreeLogger logger,
- GeneratorContext context, String partialPath)
+ GeneratorContextExt context, String partialPath)
throws UnableToCompleteException {
try {
String qualifiedSourceName = serviceIntf.getQualifiedSourceName();
@@ -881,7 +881,7 @@
return ResponseReader.OBJECT;
}
- private SourceWriter getSourceWriter(TreeLogger logger, GeneratorContext
ctx,
+ private SourceWriter getSourceWriter(TreeLogger logger,
GeneratorContextExt ctx,
JClassType serviceAsync) {
JPackage serviceIntfPkg = serviceAsync.getPackage();
String packageName = serviceIntfPkg == null ? "" :
serviceIntfPkg.getName();
===
---
/trunk/user/src/com/google/gwt/user/rebind/rpc/ServiceInterfaceProxyGenerator.java
Mon Jul 6 16:17:17 2009
+++
/trunk/user/src/com/google/gwt/user/rebind/rpc/ServiceInterfaceProxyGenerator.java
Tue Dec 21 05:37:31 2010
@@ -15,23 +15,25 @@
*/
package com.google.gwt.user.rebind.rpc;
-import com.google.gwt.core.ext.Generator;
-import com.google.gwt.core.ext.GeneratorContext;
+import com.google.gwt.core.ext.GeneratorContextExt;
+import com.google.gwt.core.ext.GeneratorExt;
import com.google.gwt.core.ext.TreeLogger;
import com.google.gwt.core
[gwt-contrib] Re: Generator Result Caching implementation for ClientBundle (issue1236801)
(The reply function doesn't publish comments)
http://gwt-code-reviews.appspot.com/1236801/diff/1/3
File user/src/com/google/gwt/resources/ext/ResourceContext.java (right):
http://gwt-code-reviews.appspot.com/1236801/diff/1/3#newcode147
user/src/com/google/gwt/resources/ext/ResourceContext.java:147: * a
given method. This data will be populated and available prior to any
method, based on the presence of an {...@link Source} annotation or the
method or the {...@link DefaultExtensions} annotation of the
ResourceGenerator.
The whole populated and available statement seems kind of a weird thing
to guarantee here.
Is there any time where it's invalid to call this method?
http://gwt-code-reviews.appspot.com/1236801/diff/1/3#newcode170
user/src/com/google/gwt/resources/ext/ResourceContext.java:170:
Whitespace.
http://gwt-code-reviews.appspot.com/1236801/diff/1/6
File
user/src/com/google/gwt/resources/rebind/context/AbstractClientBundleGenerator.java
(right):
http://gwt-code-reviews.appspot.com/1236801/diff/1/6#newcode231
user/src/com/google/gwt/resources/rebind/context/AbstractClientBundleGenerator.java:231:
Whitespace, here and elsewhere.
http://gwt-code-reviews.appspot.com/1236801/diff/1/6#newcode362
user/src/com/google/gwt/resources/rebind/context/AbstractClientBundleGenerator.java:362:
return new RebindResult(RebindStatus.USE_ALL_NEW, createdClassName,
cpi);
Where do the previously-emitted resource files live (e.g. *.cache.png)?
Are they deleted between refreshes so that staleness will become glaring
obvious?
http://gwt-code-reviews.appspot.com/1236801/diff/1/6#newcode438
user/src/com/google/gwt/resources/rebind/context/AbstractClientBundleGenerator.java:438:
long lastModified =
generatorContext.getSourceLastModifiedTime(sourceType);
How does this handle the case where a CssResource subtype is not
necessarily defined in the same compilation unit as the ClientBundle
subtype?
http://gwt-code-reviews.appspot.com/1236801/diff/1/6#newcode655
user/src/com/google/gwt/resources/rebind/context/AbstractClientBundleGenerator.java:655:
cacheable = false;
Why not just return false immediately?
http://gwt-code-reviews.appspot.com/1236801/diff/1/7
File
user/src/com/google/gwt/resources/rebind/context/AbstractResourceContext.java
(right):
http://gwt-code-reviews.appspot.com/1236801/diff/1/7#newcode142
user/src/com/google/gwt/resources/rebind/context/AbstractResourceContext.java:142:
Whitespace, here and elsewhere.
http://gwt-code-reviews.appspot.com/1236801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Generator Result Caching implementation for ClientBundle (issue1236801)
On 2010/12/21 16:02:35, bobv wrote: Bob, thanks for the comments... The mix of explicit vs. implicit dependency tracking is confusing. You have an explicit requirements.addConfigurationProperty(), but the @Source-file tracking is implicit via ResourceContext.getResourcesForMethod(). ResourceContext.getResourcesForMethod is not meant as part of any dependency tracking (implicit or explicit). It's simply a way for a ResourceGenerator implementing HasFindableResourceDependencies to go and get their resource URL's. It's there to prevent duplicate work, since AbstractClientBundleGenerator.findAllResourcesAndCheckCacheability() needs to go and find all those resource URL's anyway, I moved that process of calling ResourceGeneratorUtil.findResources() out of the individual ResourceGenerators, and do it all up front, since all those resources need to be found anyway for the purposes of checking cacheability (e.g. to compare their lastModifiedDate). This check happens before any ResourceGenerators have been instantiated, since we want to do this check before doing any extra work if it turns out we are cacheable and can bail early. The SupportsGeneratorResourceCaching interface makes sense, but the HasFindableResourceDependencies smells. Would the HFRD interface be necessary if URL dependencies were tracked explicitly? HFRD dependencies are tracked explicitly via ResourceGeneratorUtil.findResources(), and doing a check on the lastModifiedDate for each URL found. Where's the escape hatch for staleness, say if an RG wanted to depend on an arbitrary external resource? If an RG wants to depend on an arbitrary external resource, it shouldn't implement SupportsGeneratorResourceCaching, unless it comes up with a scheme on it's own to check cacheability. If we find any resource which doesn't implement this interface, it means we have to invalidate cacheability across the board. If later on, we have a new ResourceGenerator which has external resources which aren't findable via RSG.findResources, but which does have a way to check cacheability, we can develop a scheme for that. Perhaps by adding a different sub-interface in addition to HRFD, which would imply some other way to check resources (ideally without instantiating an RG first). But the present approach relies on being able to inspect things entirely via reflection, without instantiating a resource generator. I'd rather not speculatively develop interfaces for things we don't currently have, no? http://gwt-code-reviews.appspot.com/1236801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Select the correct ConstraintValidator for the bean type. (issue1238801)
LGTM On 2010/12/21 01:20:30, Nick Chalko wrote: http://gwt-code-reviews.appspot.com/1238801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Move all the TCK to the test dir in preparation for (issue1239801)
LGTM. Notice that in user/ supersource goes into user/super and supersource tests go into user/test-super. On 2010/12/21 04:26:56, Nick Chalko wrote: http://gwt-code-reviews.appspot.com/1239801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add a warning in GWTTestCase to help users that accidentally run a GWT JUnit Test as a JUnit Test. (issue1224801)
http://gwt-code-reviews.appspot.com/1224801/diff/1/2
File user/src/com/google/gwt/junit/client/GWTTestCase.java (right):
http://gwt-code-reviews.appspot.com/1224801/diff/1/2#newcode445
user/src/com/google/gwt/junit/client/GWTTestCase.java:445: // Check to
see if gwt.devjar is null. If so, notify the
On 2010/12/16 19:43:39, rdayal wrote:
Is this system property required?
This is a tough one, because I don't think it's strictly required, but
the devjar has things such as the GWT devmode bridge and the GWT
compiler. Can you think of a case where it wouldn't be set though? Let
me ask some non-GPE and non-Eclipse users to add this change and confirm
nothing breaks before asking for the LGTM.
http://gwt-code-reviews.appspot.com/1224801/diff/1/2#newcode448
user/src/com/google/gwt/junit/client/GWTTestCase.java:448:
testResult.addError(this, new Throwable("No GWT devjar property found.
Did you mean to run as a GWT JUnit Test instead of a JUnit Test?"));
On 2010/12/16 19:43:39, rdayal wrote:
Suggestion:
"No GWT devjar property found. Did you mean to run as a GWT JUnit Test
instead
of a JUnit Test?" -->
"The gwt.devjar property has not been set. If you are using the Google
Plugin
for Eclipse, you should be running this test as a 'GWT JUnit Test',
not a plain
'JUnit Test'."
Done.
http://gwt-code-reviews.appspot.com/1224801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Generator Result Caching implementation for ClientBundle (issue1236801)
The mix of explicit vs. implicit dependency tracking is confusing. You have an explicit requirements.addConfigurationProperty(), but the @Source-file tracking is implicit via ResourceContext.getResourcesForMethod(). The SupportsGeneratorResourceCaching interface makes sense, but the HasFindableResourceDependencies smells. Would the HFRD interface be necessary if URL dependencies were tracked explicitly? Where's the escape hatch for staleness, say if an RG wanted to depend on an arbitrary external resource? http://gwt-code-reviews.appspot.com/1236801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Generator Result Caching implementation for RPC (issue1235801)
http://gwt-code-reviews.appspot.com/1235801/diff/1/4 File user/src/com/google/gwt/user/rebind/rpc/ServiceInterfaceProxyGenerator.java (right): http://gwt-code-reviews.appspot.com/1235801/diff/1/4#newcode61 user/src/com/google/gwt/user/rebind/rpc/ServiceInterfaceProxyGenerator.java:61: return new RebindResult(RebindStatus.USE_PARTIAL_CACHED, returnTypeName); On 2010/12/20 21:22:58, zundel wrote: I think it would be helpful to document why you chose this RebindStatus value. Done. http://gwt-code-reviews.appspot.com/1235801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add a warning in GWTTestCase to help users that accidentally run a GWT JUnit Test as a JUnit Test. (issue1224801)
http://gwt-code-reviews.appspot.com/1224801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Generator Result Caching implementation for RPC (issue1235801)
http://gwt-code-reviews.appspot.com/1235801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on BeanValidation in google-web-toolkit
Comment by ncha...@google.com: Yes Date validation is supported, just not java.util.Calendar Validation, because the Calendar object is not supported in GWT. For more information: http://code.google.com/p/google-web-toolkit/wiki/BeanValidation -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Ensure that enum types reachable through AutoBean method parameterizations are included in the E... (issue1240801)
Reviewers: jbrosenberg, Description: Ensure that enum types reachable through AutoBean method parameterizations are included in the EnumMap. Patch by: bobv Review by: jbrosenberg Please review this at http://gwt-code-reviews.appspot.com/1240801/show Affected files: M user/src/com/google/gwt/autobean/rebind/model/AutoBeanFactoryModel.java M user/src/com/google/gwt/autobean/rebind/model/AutoBeanMethod.java M user/test/com/google/gwt/autobean/shared/AutoBeanCodexTest.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Why does OptionalFieldEditor implements LeafValueEditor?
On Mon, Dec 20, 2010 at 5:58 PM, BobV wrote:
> On Mon, Dec 20, 2010 at 11:44 AM, Thomas Broyer wrote:
>> But how do you explain the difference in display then between
>> OptionalFieldEditor (which also appears to work OK in DynaTableRf) and our
>> copy without LeafValueEditor?
>> (looks like I'll have to debug it; hopefully looking at the generated java
>> code will tell, without resorting to debugging the generator)
>
> The flow through AbstractEditorDelegate.flush() is affected by whether
> or not the editor implements LeafValueEditor. If it does, it assumes
> that the LVE's getValue() will implicitly flush all sub-editors.
> Similarly, the AED.refresh() method assumes that LVE's setValue() will
> populate the sub-editors. If you remove the LeafValueEditor
> interface, the updates would proceed through the EditorChain used by
> the CompositeEditor interface.
>
> What happens when the unmodified OptionalFieldEditor.setValue() method
> is called? It should call through the injected EditorChain with the
> new value (just as the framework would do in the modified OFE case).
Comparing the generated code between our OptionalEditor and the stock
OptionalFieldEditor:
1. the delegate for the editor itself is strictly equivalent.
2. there is a difference in the "parent" editor though: in
flushSubEditors, the setter for the property is called with the
delegate's getObject() in the case of OptionalFieldEditor, but not
with our editor (expected, given your description above).
It helped me spot an issue in our code: we wanted to give access to
some editors to the parent editor/view (a ListEditor so we could add
an item to the list, and the optional field so we could set a value,
in response to user actions) and exposed them as public methods that
happens to be detected as "sub editors" by the Editor framework:
@UiField IsEditor> foo;
...
public OptionalFieldEditor fooEditor() { return
foo.asEditor(); }
This means the ListEditor and the OptionalFieldEditor are used twice,
with 2 distinct delegates each.
I'm not sure it would cause the issue but it sure duplicates works
(well, given that AbstractEditorDelegate.Chain uses a map keyed on the
editor, it might still be it).
I've refactored the editor to get rid of the duplicates (I could have
annotated the methods with @Ignore but chose to only expose the
ListEditor#getList instead of the ListEditor itself, and the
OptionalFieldEditor as a TakesValue) and am currently testing it.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on AutoBean in google-web-toolkit
Comment by t.broyer: RequestFactory is not designed for an "RPC style" use, but using only ValueProxy I believe you could do it anyway (it could also be a first step in migrating from GWT-RPC to RF for "CRUD oriented" apps) For more information: http://code.google.com/p/google-web-toolkit/wiki/AutoBean -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on AutoBean in google-web-toolkit
Comment by david.nouls: I have the same question as mr autobeanvonautobahn. The current GWT RPC mechanism is a nightmare for interoperability and also difficult to stress test with tools like JMeter. We want the ability to reuse the RPC calls through a JSON API, with not too much handcoding. In our product we do not care too much about the potential size difference between RPC and JSON. Performance is still important, but RPC was never very performant (stackoverflow, slow javascript warnings). So I am thinking about writing a generator that combines the Autobean API with Sync/Async interfaces as used by RPC) ... although I have the impression that comes very close to the RequestFactory ... but the docs state give me the impression that it is not designed for general rpc method calling, but more for handling JPA,Hibernate stuff. For more information: http://code.google.com/p/google-web-toolkit/wiki/AutoBean -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Comment on BeanValidation in google-web-toolkit
Comment by zixzigma: is Date Validation supported ? For more information: http://code.google.com/p/google-web-toolkit/wiki/BeanValidation -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
