GWT: Decoupling Client code dependency in Server Code

[Sachin Gupta]

---

My requirement is to modularize existing GWT application so that whenever required Client code can be updated and just hot fix for Client jar can be done rather than complete application war deployment.


To achieve above requirement I modularize my existing Smart GWT code into Parent-Child modules where Child modules will be Server, Client and Shared Modules. Client, Server, Shared package of application will be present in Client, Server, Shared modules respectively.

I am packaging:-
Server Module in war.
Client Module in Jar,
Shared Module in jar as well as jar containing Source code.

I put dependencies relative to Shared package in Client and Server Module code as both will be accessing Shared Module codebase.

But when i am introducing Server Module's dependency in Client Module I am getting compilation errors in Server Module as this is against GWT convention wherein Client interface is extended in Server implementation.

Can you please help me out how can i introduce server dependency in client module to achieve my requirement.

Do let me know if you need my POC code for reference.

[Jens]

The client and server module should not know them each other at all.

If you have client interfaces that are implemented on the server (like the GWT-RPC service interface) then these interfaces belong into the shared module. For RequestFactory there are annotations that reference server classes by name instead via class literals, e.g. @ProxyForName("com.example.app.server.entities.Person") instead of @ProxyFor(Person.class).

If the above does not solve your issue you need to be more specific with your question.

-- J.

[jonl]

I do something similar, but I decided that three jars were pointless.  I have a -user jar, which contains everything and a -server jar that I use for deployment which contains everything, except source, in shared/server.

So your hotfix, then would be for the -server.jar instead of the -user.jar.  The -user jar is only needed during client side and GWT compile.

To enforce the separation and reduce the possibility of unneeded serializers, I also have a common extensive rpc.blacklist that blacklists everything in a .client. package.  There are a few exceptions to this list though, because GWT does not enforce its own client/shared/server convention in some of the older code for RPC And Servlets so there is some serializable RPC things and exceptions in the client packages that are needed if you want to do remote logging or RPC.

[Sachin Gupta]

Thanks Jonl for your reply.

So as per my understanding, correct me if I am wrong. when you tried to implement this separation of jars and client war. You created some rpc.blacklist as well to avoid some client classes to get converted to .js.

So what are the roadblocks you come across apart from the one mentioned above in order to implement it.
Did you get success in decoupling client/server/shared package.

[Jonathon Lamon]

So what are the roadblocks you come across apart from the one mentioned above in order to implement it. 
Did you get success in decoupling client/server/shared package.

So if you follow the pattern of two jars, everything in one user jar and only server accessible code in a server jar, then there are no real road blocks.  Generally, all the projects I create for GWT I actually create three source folders for, one for client, one for shared and one for server.  I guess the biggest road block is your own diligence in maintaining the separation.

Another idea in separating concerns, if the objects in question are not dependent upon GWT in any fashion, create a straight Java Project for them where GWT is not on the classpath and generate an independent jar for that project that you then include at run/compile time.  

Jonathon Lamon
Principle Software Engineer
Perceptronics Solutions Inc.
Tel  703-485-2922
Cell 269-205-4649
www.percsolutions.com

--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/4wpuH9jelFE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.