Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Moving from SmartGWT LPGL to SmartGWTPower

    We have successfully used SmartGWT LPGL for several projects and recently we have purchased SmartGWT Power license. In previous project we used much or less the same architecture where we used SmartGWT components using GWT-RPC data sources. On the server side we used Hibernate/Spring with Gilead for transferring domain objects to client side.

    Now I have project with somehow different architecture as we started to use Glassfish with JavaEE 6 and SmartGWT server support. I have few questions regarding architecture:

    - We are using EJB3 in EAR application. Do we need to write our own DataSource implementation (like in Reusable ORM example) or there is some built in support for EJB3?
    - What is preferred way for calling server side (non-datasource) actions when using SmartGWT server? Do you suggest using GWT-RPC or SmartGWT provides some better alternatives (DMI RPC, RPC Manager)? How do you compare these methods, what are pros/cons?
    - What is preferred way for i18n? I am asking this because we used GWT mechanisms for localization in SmartGWT LPGL as our data sources were client side. However, if I understood correctly, for server side ds we should use JSTL tag libraries. Do you suggest using separate message bundles for client side/server side or same file (I guess JSTL fmt tag could use same message resources file as GWT)?

    #2
    1. use JPADataSource. However consider eliminating EJB in favor of SQLDataSource (simpler, faster, more flexible).

    2. just use DataSources and the communication is transparent. You don't have to worry about it or write any code for serialization or DTOs. Read the QuickStart Guide chapter on the Server Framework chapter and pay close attention to DMI.

    3. use the same resources.

    Comment


      #3
      1. Can JPA datasource be used if I have several Persistent units in different ejb modules (my application use 2 or maybe 3 databases)? Also, I want more control over operations: For example, I need to perform several operations on the server when saving data. Or I want to mark deleted records with some status instead of performing real delete operation. Is JPA datasource flexible enough for such situations? Can JPA datasource use JTA transactions? Should I use JPA datasource or JPA2Datasource (we use JavaEE6)?

      2. My second question was about non-datasource actions (I need to perform some action when user clicks on button which is not some of CRUD operations over some data source). For example, I want to send JMS message, create some file or something like that. I guess, I don't need to create data sources for such situations. Should I use GWT-RPC for such cases or use DMI/RPCManager?

      In previous projects, I used GWT-RPC on app startup to get User object with populated roles, permissions.. and on client side I would decide which menu options to allow or not to user. Do you suggest using this approach when using SmartGWT server or there is some better way with using datasources? Is there some example for using security/authorization...?

      Comment


        #4
        1. just to reiterate, our #1 recommendation is to use SQLDataSource. Yes you can perform additional operations or return success responses for deletes or other operations without actually doing the persistent operation in JPA (see QuickStart Guide DMI sections). Use JPA2DataSource unless you have special reasons to use JPA 1.0. You can define multiple persistence units - see JPA overview in the JavaDoc. Multiple transaction management strategies are available - see JPA overview.

        2. the most convenient way is typically to use a DataSource operationBinding with operationType:"custom" and DataSource.performCustomOperation(). This is the easiest approach and allows you to put the operation on some DataSource it may be related to. You can alternatively use RPC DMI (see DMI overview). Both approaches have the key advantage over GWT-RPC that the operations can then be queued with other DataSource operations (in addition to all the advantages listed in the FAQ).

        Take a look on the public wiki (wiki.smartclient.com) for some examples of setting up authentication and Declarative Security with various systems (Tomcat Realms, Spring Security, JBoss LDAP, etc).

        Comment


          #5
          Is there some examples how to configure JPA2 Datasource used in application packaged in EAR file? I have EAR application with several modules (ejb-jars and war file).
          I have tried to configure JPA2Datasource without success. At first, my persistent unit was defined in ejb-jar file (Smartgwt libraries are in war/lib). It seems that this does not work as war file cannot access PU defined in ejb-jar file. I have tried to move PU in separate jar file under lib folder in EAR file. Now, war file can "see" persistent unit, but I am getting errors when JPA2Datasource is being initialized.
          Do you have some example of such configuration for Glassfish 3 (JavaEE6)? Where should I put SmartGWT server libraries, in EAR lib or WAR lib folder?


          Regarding your recommendation of using SQLDataSource, is your suggestion to get rid of JPA/Hibernate completely from application, or to use SQLDataSource for CRUD only and JPA/Hibernate for the rest of application (for example some logic that is not initiated from UI, scheduled tasks etc...)?

          Comment


            #6
            This is a great example of why you should use SQLDataSource. No weird issues with deployment of persistence units, and no mysterious undebuggable errors when something goes wrong.

            We don't know of special steps for .ear deployment - if you want to continue with JPA you should post your actual configuration and the error messages that result.

            Yes, use SQLDataSource for command-line and scheduled tasks. It's great at this, and there's a dedicated topic in the docs for how to build command-line apps using the SmartGWT server framework.

            Comment


              #7
              OK, I managed to configure it. The problem was that I had com.isomorphic.jpa.EMFProviderCMT as EMF provider and I later found out that this should be used when datasource is called from EJB (I am not sure why would I use that but it is definitely not my case). When I switched to com.isomorphic.jpa.EMFProviderBMT it started to work.

              Guys, don't get me wrong, but you really need to improve documentation! I would expect some developer guide where I would have all information which is now located in various javadocs, pdfs, wikis etc. For example, I still haven't found complete reference of DataSource xml file.

              Btw, do you plan to add CDI support (JSR-299) to SmartGWT? Something similar to Spring support you already have.

              Comment


                #8
                There is a complete reference to the properties of .ds.xml here. This is prominently listed under available resources in the intro section of the QuickStart Guide.

                What do you have in mind in terms of JSR-299? What features would be added to SmartGWT to support this?

                Comment


                  #9
                  Hm, I would expect some examples in the docs. Also, it is not obvious on this page which elements/attributes are required for each type of DataSource. Note that most users don't have time to read all documentation (I don't!). They usually try to find some information they currently need so it is very important to make things obvious. You have great product, with many useful features but trying to use some of them can take great amount of time.

                  Btw, is there some reference of properties in server.properties file except the file itself?

                  Regarding CDI, for example I would like to lookup ServerObject in CDI context just like it is possible to lookup Spring object by name. Also, seems to me that it would be useful if custom datasource could be looked up as bean in Spring/CDI context so that DI can be performed on it.

                  Comment


                    #10
                    Sorry, don't follow. You want the examples inlined in the docs? What for? The docs link to the examples, and that way you can see them running.

                    Properties that can set in server.properties are mentioned in the docs about the specific feature that has a possible setting in server.properties. This also seem to be as it should be, as a single reference would cut incoherently across unrelated subsystems.

                    Thanks for pointing out CDI - yes we will probably support it in a manner similar to Spring, and you get it supported right away if you sponsor it.

                    Comment


                      #11
                      Dejan,

                      I agree with you, it's a great product but there's a huge gap in the documentation. Despite the huge amount of functionality in SmartGWT, I've been extremely frustrated with it.

                      There's a Quick Start and there's the JavaDocs, but there's no topical reference. They've tried to merge the subject reference into the javadocs but you can only find things if you already know what you're looking for. The learning curve is very steep.

                      Also, the configuration documentation is split between the SmartGWT Javadocs and the SmartClient Javadocs. Be sure to check the SmartClient Javadocs for information about the server side functionality.

                      Comment


                        #12
                        Originally posted by Isomorphic
                        Sorry, don't follow. You want the examples inlined in the docs? What for? The docs link to the examples, and that way you can see them running.
                        I am just giving my feedback as someone who spent more time that I think it is needed to accomplish something that does not seem that complicated in the end. You can use it or not, I am fine with both. I pointed out what information I couldn't find quickly when I needed. Maybe other users are fine with current state of documentation and maybe they use it differently than me, but I don't think Javadoc is the best way to document features. I think it would be easer if documentation is in single reference document with more examples in it for various configurations.

                        Regarding server.properties, I think it is OK to have properties explained in the docs of specific features, but I also think it would be useful to have them listed in the single place with simple explanation and links to the documentation of specific feature where it is explained with more details. When I start new project I would like to know which properties are required and which not. I don't want to read full documentation to find out that if I can remove some property.

                        Comment


                          #13
                          We'd love to improve the documentation further, but we can't do much with feedback that isn't specific about what's missing (or worse - is inaccurate).

                          @evanross the JavaDoc contains dozens of topical overviews represented as Java interfaces in the "docs" package. There are pervasive links to these overviews on related properties to ensure they cannot be missed. Also, what "SmartClient JavaDocs" are you referring to? Did you mean the server reference? We're not aware of places where information is "split" - can you be specific?

                          As far as finding things within the docs, if you are not already using search, be sure to use search. If there's something specific you feel is not well covered, tell us about it - looking over your recent interactions with support, we can't see any instances of something you've had trouble finding.

                          @dejan as far as we can tell, you're unhappy with format (JavaDoc) but not content. Sorry, but we're unlikely to move away from JavaDoc, given it's familiarity to developers and the number of tools that understand it.

                          Comment


                            #14
                            Regarding the "split" documentation, my guess is that @evanross is referring to the JavaDoc of com.isomorphic.* vs. the JavaDoc of com.smartgwt.*

                            As one's trying to come up the learning curve of this very big product, one encounters both, including com.isomorphic.datasource.DataSource and com.smartgwt.client.data.DataSource, both of which have interesting and possibly relevant subclasses. Yes, I get it, one is client-side and one is server-side.

                            Comment

                            Working...
                            X