Announcement Announcement Module
No announcement yet.
@RooEntity and GWT Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • @RooEntity and GWT

    Hi guys,

    I have done recently a lot of experimenting/prototyping with ROO and GWT. One of the things I have tried is to use a shared domain model between GWT and ROO generated backend, e.g. use Roo entities directly into GWT. There are pros and cons to this, the main two pros I see are

    1.) No need for maintaining DTOs
    2.) Simplicity, by using the default GWT remoting mechanism which understands serializable types

    There are two main issues wit this however:
    a.) Aside @RooToString annotation any other annotation will cause any GWT remoting to fail with a " tion: Invalid type signature for ... classnamehere"
    b.) GWT needs the source when it compiles, so we cannot make use of @RooJavaBean for getters/setters AspectJ waving into the compiled domain class

    While the above is not the cleanest way to integrate GWT with Roo, the architecture is arguable and also error prone regarding to LazyInitialization issues (add Hibernate usual detached object issues and on top of that add GWT serialization), it is still quite simple and straightforward. Also it doesn't exclude the usage of other architectural styles to integrate GWT with ROO :-)

    The question is: Is there any way to work around issues a.) and b.) Ideas of how to do it ? And if it doesn't work, what's everyone's stake of how ROO could be easily integrated with GWT w/o losing the @RooEntity support ?


  • #2
    Personally I think the cleanest model is to use JSON. But this is non-trivial either and you have to then tackle object assembly plus of course consuming and creating JSON documents on the client side.

    As per our off-list emails, separately I'm looking into GWT in depth and this will include exploring the most feasible model. Until then I can't really offer specific suggestions unfortunately.


    • #3
      After exploring the "common domain model" alternative for a while I tend to believe this has several severe drawbacks, the biggest one being that I can't see how we can use the @RooEntities as they are.

      One alternative is to use JSON with overlay types on the GWT-UI side but at the same time I am wondering if we are to generate the overlay types why convert them to JSON and back over the wire ? We can directly transfer them through GWT serialization mechanism avoiding JSON serialization/deserialization altogether.

      Also we could make it pluggable/configurable


      • #4

        Sorry to come to this discussion only with questions im completely new to GWT so maybe im asking some stupid question, im interested too in integration with other web technologies, primarly based in XML aproaches for the UI. And i would like to ask a few questions to you guys.

        From your discution you seem to want to use GWT and its RPC capabilities to comunicate with your Roos based backend and so i see the issues you described, also GWT is a java based technollogy wich needs compilation. Am i correct??

        I allways thougth the best way to integrate Roo with other web technollogies is via WS, after all Roo generates all rest endpoints you need, the JSON aproach seems like that idea. Is JSON processing such a big drawback?? Or is something related to GWT in particular?? I thougth that with Spring MVC content-negotiation and views it could be very easy to implement a JSON based endpoints, and the hibernate issues could be resolved using a sort of JSON DTO instead of serialize entities.

        Am i saying something stupid???

        Thanks, Raul


        • #5
          Certainly you're not talking nonsense. Actually I would encourage everyone to give input on this matter.

          GWT indeed is a Java based technology which needs compilation, only that it takes compilation a step further and it doesn't need the bytecode only, aka the .class file when compiling the GWT module (we are talking about GWT compilation step which translates Java to JavaScript eventually) but also the source code of the module classes and source code for dependent modules.

          As a 100% UI side technology (after compilation what GWT gives you is pure HTML + Javascript), aside it's own default remoting mechanism through async interfaces, GWT has plenty of room for different remoting solutions, being able for example to make an AJAX call to the server side and from there you could develop your thing :-). It comes though with it's own remoting service mechanism and it's own (object) serialization policy, which are very well thought and efficient and I was looking at a way of using that.

          But it comes to me more and amore each time I think of this that this mechanism should be made

          1.) pluggable
          2.) configurable

          So that people could choose for example if they want to go with GWT remoting, JSON remoting or develop their own bit of functionality based on the excellent Gilead library for example.

          The answer to your last question is NO, you didn't say anything stupid :-) Thanks for the input.


          • #6
            Dorel, could you think of using Vaadin instead ( It's GWT based library and there should be no problems using Roo entities.


            • #7
              That is a HUGE idea ! A Vaadin ROO plugin would make total sense since it's a end to end framework and I assume all one would have to do is use their components/libraries w/o anything else. However I think that would be a different plugin altogether. Thanks for the suggestion, I'll take a look at it for sure.


              • #8
                Hello dorel, did you have sucess doing the integration between Roo and GWT? I would be really interested on this because we are near to start a project with GWT and i would like to use Roo too...


                • #9
                  It would be good if people who are keen on this support could create a bullet-point list of their use cases or key requirements (preferably in order of criticality). I am in active ongoing discussions about our GWT support for Roo and accordingly the input would be invaluable.



                  • #10
                    Support for Roo w/ GWT - Bullet-point List

                    Today was the first day that I created my SpringSource account and did so for the soul purpose of responding to this post.

                    I am looking at the architecture for a application that will use Roo on the backend (handling all of the Hibernate pieces/ and all of the other amazing things that Roo does) and the GWT UI on the front end for its excellent RPC design. It is the perfect combination of Java technologies.


                    Your points are great. There are issues that I am directly faced with. I am very curious to know if the Vaadin plugin worked well.


                    This is just a start to the bullet-point list.

                    1. Include option for automatic UI generation in GWT with the Roo project initialization to include basic RPC plumbing with Roo enties.



                    • #11
                      GWT support work

                      I'm interested in GWT support in Roo as well. Are there any public discussions on this anywhere yet? I would be willing to contribute to a code effort to provide GWT support.


                      • #12
                        Vaadin Roo Plugin

                        Originally posted by dorel View Post
                        That is a HUGE idea ! A Vaadin ROO plugin would make total sense since it's a end to end framework and I assume all one would have to do is use their components/libraries w/o anything else. However I think that would be a different plugin altogether. Thanks for the suggestion, I'll take a look at it for sure.
                        You are correct - GWT and Vaadin are quite different beasts. In Vaadin you code runs on server-side and there is no need for Java-to-JavaScript compilation. The end result is that Vaadin application doesn't have to include any custom RPC or client-side code at all. It just server-side Java that can integrate directly with all Spring API:s.

                        Vaadin Roo plugin is under development. A "pre-alpha" quality plugin can be built from

                        All comments on the plugin are very welcome.

                        The goal is to get the first feature complete version to be ready by the end of the year.

                        We plan to include also wysiwyg editing of the produced UI:s with full round-trip to Java code. (One can use the plugin without wysiwyg editor as well of course).

                        For a quick peak of the (also work in progress) wysiwyg editor, see:
                        Or install eclipse plugin from
                        (Yes, the editor is also built in Vaadin in order to make it easy integrate to Netbeans, IDEA and other IDE:s; already works in STS of course).