Sorry, as I wrote that last response, I realized that I was incorrect. Reflection does not come into play when dealing with GWT RPC types, since GWT's RPC servlet must know about all possible types that could be sent across the wire. I believe that GWT's RPC generator will compute the exact set of types from the GWT client code which are necessary. Then, we'd have to look over the entire set of types that were compiled from client source (by looking at the module's source path), and remove all of those classes except those that are part of the set found by the RPC generator. So, in short, you're right - it is a tricky problem. If we had a notion of "shared" client and server code in a GWT module, this problem would be much easier.
On Wed, Jun 24, 2009 at 1:48 PM, Rajeev Dayal <rda...@google.com> wrote: > Hey Thomas, > Responses inline: > > On Wed, Jun 24, 2009 at 12:19 PM, Thomas Broyer <t.bro...@gmail.com>wrote: > >> >> >> >> On 24 juin, 17:00, Rajeev Dayal <rda...@google.com> wrote: >> > Hi Clanusse, >> > >> > You are right - the only class files that are needed are those that are >> used >> > by RPC, which are: >> > >> > -your sync interface >> > -any types that can be passed across the wire over RPC >> > -your server-side classes (including the implementation of your sync >> > interface) >> > >> > Unfortunately, the plugin's deployment mechanism is not smart enough to >> know >> > which types are purely client and purely server. To do this, the plugin >> > would have to interpret GWT's module information, which it does not do >> right >> > now. This is a feature that will be available in a future version of the >> > plugin, and at that time, we should be able to "smarten up" the >> deployment >> > mechanism so that it excludes GWT client classes from >> war/WEB-INF/classes. >> >> Er... and if you happen to have a "shared" subpackage that contains >> shared client+server classes?! > > > Yes, you're right - that's what I was referring to when I said "any types > that can be passed across the wire over RPC". > > >> >> >> I guess the plugin would rather have to interpret the non-client >> classes and bring in any dependency found in the GWT client packages >> (this would include the RPC "sync" interfaces for instance and "any >> types that can be passed across the wire over RPC"). >> Much more difficult than "interpret[ing] GWT's module information"... > > > Yes, you are right - I was summarizing when I said "Interpret GWT's module > information". What I meant is that at the least, we'd have to analyze GWT > modules, which we do not do now. The problem with analyzing the non-client > classes is that you can never be sure classes in the GWT client packages > will be referenced, due to reflection. > > In order to solve this problem, we may have to add some more information to > GWT modules so that "shared" code can be called out explicitly. > > >> >> >> > --~--~---------~--~----~------------~-------~--~----~ 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-Toolkit@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 -~----------~----~----~----~------~----~------~--~---
