Thanks Thomas, that helps. (I think serverTypeToProxyTypes might be a better name.)
I was curious about how often this code it gets run. It looks like it happens on every RPC call though this path: SimpleRequestProcessor.processInvocationMessages() -> ResolverServiceLayer.updateDeobfuscator() -> Deobfuscator.Builder.merge() I would expect that once it's warmed up, most of the time there is no actual change to the map (the classes are already in there), and yet for each (key,value) pair in the map of all server types, it will build a new TreeSet, merge the proxy types that are already there (using a pretty slow comparator), and make it immutable again, on every RPC call. This seems kind of inefficient. Is there something we can do to make the common case fast? - Brian On Thu, Sep 6, 2012 at 2:11 PM, <t.bro...@gmail.com> wrote: > > https://gwt-code-reviews.appspot.com/1712803/diff/2001/user/src/com/google/web/bindery/requestfactory/vm/impl/Deobfuscator.java > File > user/src/com/google/web/bindery/requestfactory/vm/impl/Deobfuscator.java > (right): > > https://gwt-code-reviews.appspot.com/1712803/diff/2001/user/src/com/google/web/bindery/requestfactory/vm/impl/Deobfuscator.java#newcode122 > user/src/com/google/web/bindery/requestfactory/vm/impl/Deobfuscator.java:122: > private Map<String, List<String>> merge(Map<String, List<String>> > domainToClientType1, > On 2012/09/06 19:21:57, skybrian wrote: > >> Hmm. Thanks, but I'm still rather lost and need some context, probably > > because I >> >> don't understand the RequestFactory wire protocol. > > > I'll try to shed some light (though ti has nothing to do with the wire > protocol actually). > > >> To be specific, what is a "domain"? > > > Domain types are the kind of objects pointed to by > @ProxyFor/@ProxyForName annotations on proxies (which are here called > "client types") > > >> What's an example key to this map? > > > In the MobileWebApp sample, that would be > "com.google.gwt.sample.mobilewebapp.server.domain.Task" (a domain type's > binary name). > >> What is the value? > > > The list of "client types" mapped to that "domain type", ordered from > the most to the least specific. That is, the proxies with a @ProxyFor or > @ProxyForName pointing to that domain type, and all their > super-interfaces. > In the MobileWebApp sample, for the Task domain type, the values would > be (in order) "com.google.gwt.sample.mobilewebapp.shared.TaskProxy" and > "com.google.web.bindery.requestfactory.shared.EntityProxy". > But you can map several proxies to the same domain type, in which case > you'd have more than that. > > >> Why would we have multiple values for the same key? >> What is this map for, anyway? > > > The map is used when constructing the response. > > > > Let's say I have an Employee and Manager (extends Employee) domain > types, and an EmployeeProxy with @ProxyFor(Employee.class). Some method > (a service method, or a getter in another bean) has a return type of > Employee on the server-side (mapped as EntityProxy on the client-side). > The value could very-well be a Manager in practice. > > This is where the map comes into play: which client type should be used? > > RF will take the returned value's class (say, Manager) and looks for a > corresponding proxy type that extends EmployeeProxy (because the client > method's return type is EmployeeProxy). > First case: there's no entry with Manager as key, so RF looks at the > superclass. It finds an entry for Employee, with values EmployeeProxy > and EntityProxy. EmployeeProxy matches, so let's use that. > Second case: there's a ManagerProxy extends EmployeeProxy with > @ProxyFor(Manager.class), so RF will find an entry with values > ManagerProxy, EmployeeProxy and EntityProxy. ManagerProxy extends > EmployeeProxy (the type we look for), so let's use that: the client will > receive/reconstruct a ManagerProxy. > Third case: there's a ManagerProxy with no relationship to > EmployeeProxy, and with @ProxyFor(Manager.class). RF will find an entry > for Manager with values ManagerProxy and EntityProxy. Nothing matches > EmployeeProxy, so let's look at the superclass. There's an entry for > Employee with an exact match (EmployeeProxy). > > There's also a fourth case: you have some "heavy-weight" domain object > with many properties, so you map it with 2 proxies: one for all the > properties, and a "lightweight" one with only a few properties (used for > lists of such proxies, e.g. in search results or in a value picker). > Let's say I have a Message domain type (with subject, date, recipient, > sender and body properties), and I map it with 2 proxies: MessageProxy > with all same properties and MessageProxyLite mapping only subject, date > and sender (with no inheritance relationship between both proxies). > The entry in the map for Message will have values MessageProxy, > MessageProxyLite and EntityProxy. > > And of course, all those cases can be mixed and matched. > > https://gwt-code-reviews.appspot.com/1712803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
