Announcement

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

    Using RPCManager constructor in a Servlet throws Exception

    Hi Isomorphic,

    I'm trying to use the serverside RPCManager constructor in a standalone servlet (cron-job triggered mail processing, see this thread). Right now, I'm hitting the servlet with a browser.

    I registered the Servlet in web.xml and it is accessed as expected. My code is:
    Code:
    import java.io.IOException;
    import java.math.BigDecimal;
    import java.util.HashMap;
    import java.util.Map;
    
    import javax.servlet.ServletException;
    import javax.servlet.http.HttpServlet;
    import javax.servlet.http.HttpServletRequest;
    import javax.servlet.http.HttpServletResponse;
    
    import com.isomorphic.datasource.DSRequest;
    import com.isomorphic.datasource.DSResponse;
    import com.isomorphic.datasource.DataSource;
    import com.isomorphic.rpc.ClientMustResubmitException;
    import com.isomorphic.rpc.RPCManager;
    import com.isomorphic.sql.SQLTransaction;
    
    public class SendMail extends HttpServlet {
    	private static final long serialVersionUID = -7397909713823548814L;
    
    	@Override
    	public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    //		response.setContentType("text/html");
    //		response.setCharacterEncoding("UTF-8");
    		try {
    			RPCManager rpcManager = new RPCManager(request, response); [B]//exception[/B]
    			rpcManager.setUserId("2");
    			...
    			} catch (ClientMustResubmitException exception) {
    			return;
    		} catch (Exception e) {
    			response.getWriter().append(e.getMessage());
    		}
    	}
    
    	@Override
    	public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    		doGet(request, response);
    	}
    }
    For the line "RPCManager rpcManager = new RPCManager(request, response);" I get the exception "Non-RPC request ignored.", but from the linked javadocs I think this is how to use the constructor.

    Am I doing anything wrong (I'm using v9.1p_2014-08-17)?

    Thank you,
    Blama
    Last edited by Blama; 22 Aug 2014, 05:08. Reason: corrected constructor call

    #2
    Hi Isomorphic,

    as addition, I'm using plain SmartGWT, no Struts involved.

    Best regards,
    Blama

    Comment


      #3
      Hi Isomorphic,

      as explanation, why I want to have a RPCManager:

      I call the Servlet when not logged in. All my .ds.xml have a field <field name="MODIFIED_BY" type="modifier" />. That field is NOT NULL in the DB.
      If I want to update an entry in my servlet, the generated UPDATE includes a MODIFIED_BY = NULL-clause in the SET-part.
      Somehow I have to call myRPCManager.setUserId().
      Also, I'd like to use the transaction-control features that I have with a RPCManager.

      Best regards,
      Blama
      Last edited by Blama; 22 Aug 2014, 05:06.

      Comment


        #4
        Hello Blama,

        As of version 10.1 of SmartClient the way transactions are dealt with will change. Transactions will be split out from the RPCManager and instead handled by a separate class called DSTransaction. If you intend to use transactional support in your standalone servlet we recommend that you use 10.1 and the new structure for transactions.

        With this structure you would do the following in your servlet.

        1. Create a DSTransaction, set it's transaction policy if required.
        2. Creata a DSRequest, set the DSTransaction on it to make the request part of the transaction. Populate the DSRequest with your data.
        3. Optionally call DSRequest.setUserId() to ensure the modifier fields get populated with the correct user id.
        4. Call DSRequest.execute()
        5. Go back to step 2 for each DSRequest you want to be included in this transaction
        6. Clean up transaction with DSTransaction.complete(), ideally inside a finally block.

        For more information and a more detailed example have a look at "Standalone DataSource Usage" in the SmartClient 10.1 reference documentation.

        Regards,
        Isomorphic Software

        Comment


          #5
          Hi Isomorphic,

          that sounds great for the future. I'll definitely look it up, thanks for the hint. To reassure:

          sc.com/smartgwtee-latest/server/javadoc is 5.0d, correct? The 5.1d docs I'll only have included with the download from http://smartclient.com/builds/SmartGWT/5.1d.

          Do you suggest to use 5.1d already in productive environments? I have no automated testing, so with respect to the text in http://smartclient.com/builds I'd really like not to use d-builds.

          As the transaction feature is not that important for me (don't need it just yet and if so, I could possibly work around it), but it would be great to have the setUserId(), could you backport that one to the 4.1p DSRequest, if it is not too deeply connected with the other changes?

          Best regards,
          Blama
          Last edited by Blama; 26 Aug 2014, 00:54.

          Comment


            #6
            At this stage both 5.0d and 5.1d are pre-release builds (development builds), but 5.0 is on the cusp of release, and actually very well tested and stable at this point.
            We won't officially call it "production ready" until it is released and we switch to "p"-suffixed builds, but at this stage major new development on that branch is frozen and we're really just finalizing it for release.

            5.1d is still a development build however, so we can't guarantee its stability in a production environment.

            Regards
            Isomorphic Software

            Comment


              #7
              Hi Isomorphic,

              that's what I thought. So no 5.1 for me :)

              As the transaction feature is not that important for me (don't need it just yet and if so, I could possibly work around it), but it would be great to have the setUserId(), could you backport that one to the 4.1p DSRequest, if it is not too deeply connected with the other changes?

              Best regards,
              Blama

              Comment


                #8
                Unfortunately because the addition of setUserId to DSRequest is not just a compatibility change or fix but a new feature we will not be back-porting that functionality.

                Regards,
                Isomorphic Software

                Comment


                  #9
                  Hi Isomorphic,

                  I had a look at the 5.1d StandaloneDataSourceUsage docs and it looks really promising for my use case! Thanks a lot.
                  I noticed that 5.1d DSRequest does not yet have javadocs for setUserId(String), but the method is already there, which is also great!

                  A very related enhancement suggestion is the following:
                  I described my loginname->userId setup in this post.
                  Now, if a declarativeSecurityCheck fails, the user gets the message: "User 123 (a number!) has not the required role...".

                  This is not that nice, as the user does not know about his or hers internal ID (and should not).

                  Could you implement such thing as:
                  • setUserId(String) (already there) + setUserId(int) + setUserName(String) in RPCManager and DSRequest
                  • If setUserId(String) is used:
                    • use the given Id in type="creator" and type="modifier"-fields as well as error messages (done currently).
                  • If setUserId(int) + setUserName(String) is used:
                    • use the Id (so 123 instead of '123') in the SQL-String for type="creator" and type="modifier"-fields.
                    • use the Name in error messages.


                  Best regards,
                  Blama

                  Comment


                    #10
                    We'll add JavaDoc for dsRequest.setUserId().

                    We don't plan to add the ability to have separate display value for userId - your application should designed so that users do not directly encounter Declarative Security error messages, which are not internationized and contain other values such (such as role or capability names) which are also internal identifiers.

                    Comment


                      #11
                      Originally posted by Isomorphic View Post
                      your application should designed so that users do not directly encounter Declarative Security error messages, which are not internationized and contain other values such (such as role or capability names) which are also internal identifiers.
                      That is true. I'll see where to internationalize (and log) these. Once that is done, there is no need for my suggestion anymore.

                      Best regards,
                      Blama

                      Comment


                        #12
                        Anyone hitting this thread via search: See this thread for 5.1p.

                        Comment

                        Working...
                        X