2 RequestFactory with 2 differents Proxy on the same domain class

76 views
Skip to first unread message

Alexandre Ardhuin

unread,
May 9, 2012, 10:24:22 AM5/9/12
to google-we...@googlegroups.com
Hi All,

I have an application with 2 gwt modules. Each module uses its own RequestFactory and its own Proxy for the same domain object (ie. 2 RequestFactory with 2 differents Proxy on the same domain class).
The first RF call succeeds and following RF of the same type too but when the other RF is used an exception occurs :
"The domain type Xxx cannot be sent to the client"

After some tests, the problem occurs only for 2 RF. Having only one RF with 2 Proxy on the same domain object works well.

The problem seems to be in com.google.web.bindery.requestfactory.vm.impl.Deobfuscator.Builder.merge(Deobfuscator). Doing the following modification resolves it.

    public Builder merge(Deobfuscator existing) {
+      Set<String> domains = new HashSet<String>();
+      domains.addAll(d.domainToClientType.keySet());
+      domains.addAll(existing.domainToClientType.keySet());
+      for (String domain : domains) {
+        Set<String> clientTypes = new HashSet<String>();
+        clientTypes.addAll(d.domainToClientType.get(domain));
+        clientTypes.addAll(existing.domainToClientType.get(domain));
+        d.domainToClientType.put(domain, Collections.unmodifiableList(new ArrayList<String>(clientTypes)));
+      }
-      d.domainToClientType.putAll(existing.domainToClientType);
      d.operationData.putAll(existing.operationData);
      // referencedTypes recomputed in build()
      d.typeTokens.putAll(existing.typeTokens);
      return this;
    }

Can someone confirms this is a bug ? (I haven't found any issue on that)

Alexandre

Thomas Broyer

unread,
May 9, 2012, 10:47:47 AM5/9/12
to google-we...@googlegroups.com
Yes, please file a bug for that.

As far as the patch goes, your processing loses the "most-to-least-derived type" ordering of the domainToClientType values that Deobfuscator#getClientProxies mandates.

Thomas Broyer

unread,
May 21, 2012, 6:12:16 AM5/21/12
to google-we...@googlegroups.com


On Wednesday, May 9, 2012 4:47:47 PM UTC+2, Thomas Broyer wrote:
Yes, please file a bug for that.

As far as the patch goes, your processing loses the "most-to-least-derived type" ordering of the domainToClientType values that Deobfuscator#getClientProxies mandates.

Thinking about it now, it looks like some simple Set processing could work, without the need to resolve Class<?>s and compare them, because the lists in both deobfuscators are already "complete" wrt inheritance hierarchy: using A and B ordered sets as input, the resulting list C = (A-B) + (B-A) + intersection(A,B), or more simply: C = (A-B) + B.
The idea is that everything that's not already in the list wouldn't change the result; this assumes however that the deobfuscators have been created from the same interface hierarchies (e.g. if in one case the list were C,B,A, where C extends B, and B extends A; and in the other case the list were C,A, with C extends A, then constructing a "merged list" B,C,A would be wrong; that's really an edge-case and I wouldn't bother if that failed).

Something like:
  LinkedHashSet<String> a_only = new LinkedHashSet<String>(d.domainToClientType.get(domain));
  a_only.removeAll(existing.domainToClientType.get(domain));
  ArrayList<String> new_list = new ArrayList<String>(a_only);
  new_list.addAll(existing.domainToClientType.get(domain));

Alexandre Ardhuin

unread,
May 21, 2012, 8:20:26 AM5/21/12
to google-we...@googlegroups.com
2012/5/21 Thomas Broyer <t.br...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/-5wv6ELRH7kJ.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

Your solution seems to work quick and well in 99% of the cases.
However, thanks to com.google.web.bindery.requestfactory.server.ServiceLayerCache, the resolution and comparasion of classes will be done only once (and only on merges). So I would prefer to cover 100% of the cases and thus skip some really hard debugging in the edge-cases.
Reply all
Reply to author
Forward
0 new messages