Announcement

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

    SmartGWT EE, DMI and GWTShell

    Hello,

    I have my app working in deployed mode putting the myds.ds.xml and myds.ds.jsp files in a shared/ds directory in the web root. This doesn't work in the GWT Shell as it expects "shared" to be a module to be loaded from a 'shared.gwt.xml' file.

    Should these be put into the public directory of the module and then the path to it put in server.properties? Example:

    project.datasources: $webRoot/com.mycompany.module.ModuleName/ds

    Am I also correct to assume that currently we must define DMI DataSource(s) in XML as I don't see a setServerObject(String dmiClassName) method on the DataSource class?

    #2
    BTW, congrats on the public beta of the EE product. :-)

    Well, I tried that out and it still fails as ds is null.

    Code:
    DataSource ds = DataSource.get("remoteUserDMI");
    ds.fetchData(new Criteria(), new DSCallback() {...
    This may have to do with the following:

    [java] === 2009-03-25 17:47:19,502 [main] DEBUG ISCInit - Verifying webroot: C:\Documents and Settings\cs15667\My Documents\EclipseProjects\rome2\oca-web\tomcat\webapps\ROOT
    [java] === 2009-03-25 17:47:19,502 [main] ERROR ISCInit - Can't find marker file for webRoot: C:/Documents and Settings/cs15667/My Documents/EclipseProjects/rome2/oca-web/tomcat/webapps/ROOT/com.ray.oca.gwt.OcaApplication/sc for configured/autodetected webRoot - if you moved the 'isomorphic' directory, please set isomorphicDirRootRelative in server.properties to the new location and restart the servlet engine.

    The setting is set as follows.

    isomorphicPathRootRelative: com.ray.oca.gwt.OcaApplication/sc

    Later it seems to find the jsp but can't find the skin.

    [java] === 2009-03-25 17:47:56,097 [sor4] INFO Compression - /com.ray.oca.gwt.OcaApplication/com.ray.oca.gwt.OcaApplication.nocache.js: 21590 -> 6333 bytes
    [java] === 2009-03-25 17:47:56,550 [sor3] INFO Download - File __USE_CONTAINER__/com.ray.oca.gwt.OcaApplication/sc/skins/Enterprise/load_skin.js not found, sending 404
    [java] === 2009-03-25 17:47:56,550 [sor3] DEBUG ProxyHttpServletResponse - sendError(404) - unwrapping (CompressionFilter)
    [java] === 2009-03-25 17:47:58,205 [sor4] INFO RequestContext - URL: '/com.ray.oca.gwt.OcaApplication/ds/remoteUserDMI.ds.jsp', User-Agent: 'Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)': MSIE with Accept-Encoding header, ready for compressed JS

    Thanks for any help,
    Eric

    Comment


      #3
      A few questions :

      - Are you using a structure similar to the gwt-maven based build that the EE examples use? Did you try successfully building / running and of these samples?

      - Were you able to get your app running in web mode (ie without the GWT Shell)

      Since your project has a real server component, you will need to run the GWT Shell in -noserver mode. Are you doing this?

      Comment


        #4
        I am using a similar structure to the gwt-maven apps. I setup and ran the maven as in the docs. I have only deployed the showcase to my oc4j container and that works. Was I suppose the run mvn for each pom.xml in each sample? I'm not familar with maven, obviously.

        My app runs fine if I run the GWTCompiler and deploy it to my container. Without datasources the app runs fine in the Shell. So I added the SmartGWT EE server setup to the web.xml of the GWT tomcat instance. One thing I left out is the <jsp-config> section as I didn't know the purpose of the <jsp-property-group> stuff. My container doesn't complain without the <taglib> but perhaps the tomcat does.

        I'm not using the -noserver mode as I really didn't understand that option. I do have the GWT In Practice book so I can read about that more carefully. So the GWT shell points to the port of my OC4J server instead of starting tomcat when you use -noserver? So that means the shell helps for front end only changes and debugging or also the DMIs in the server directory of the module too? The DMIs run in the deployed app I would think?

        Comment


          #5
          Originally posted by erickr
          I am using a similar structure to the gwt-maven apps. I setup and ran the maven as in the docs. I have only deployed the showcase to my oc4j container and that works. Was I suppose the run mvn for each pom.xml in each sample? I'm not familar with maven, obviously.
          Each individual sample has its own maven build. You do not need to run all of them. I was just asking to make sure I understand your setup.

          Originally posted by erickr
          My app runs fine if I run the GWTCompiler and deploy it to my container. Without datasources the app runs fine in the Shell. So I added the SmartGWT EE server setup to the web.xml of the GWT tomcat instance. One thing I left out is the <jsp-config> section as I didn't know the purpose of the <jsp-property-group> stuff. My container doesn't complain without the <taglib> but perhaps the tomcat does.
          Yes, those entries in the jsp-config can be left out.

          I'm not using the -noserver mode as I really didn't understand that option. I do have the GWT In Practice book so I can read about that more carefully. So the GWT shell points to the port of my OC4J server instead of starting tomcat when you use -noserver? So that means the shell helps for front end only changes and debugging or also the DMIs in the server directory of the module too? The DMIs run in the deployed app I would think?
          The regular GWT hosted mode can only run GWT-RPC related functionality. If you're using actual code that, say, talks to a database or uses backend services, you will need to run the server separately as a regular web app and then launch the GWTShell with the -noserver option pointing to your running server. This will allow you to run the client-only portions in hosted mode allowing you to debug etc while pointing to the server for communications.

          Setting up -noserver the first time can be a little painful so make sure you read up the docs carefully.
          Last edited by smartgwt.dev; 26 Mar 2009, 10:10.

          Comment


            #6
            Thank-you for your help. I understand much better now.

            Originally posted by smartgwt.dev
            Setting up -noserver the first time can be a little painful so make sure you read up the docs carefully.
            I just changed my launch script to point to the correct port and added -noserver and the GWTShell works great. My current generated app from GWTCompiler just sits inside my WebContent (using Eclipse) so since GWTShell points to the same required files, ModuleName.html, ModuleName.nocache.html, initsc.js(book says gwt.js) and hosted.html according to the book, I guess that is all that is required.

            Comment


              #7
              Excellent!

              Comment


                #8
                Hi,

                I just moved away from using JavaScript for developing the front end of my application to straight Java and I also have custom server code which runs in a separate instance of Apache, and I suspect that I also need to use the -noserver option so that when I run my front end app in Eclipse it connects to the existing instance of Apache.

                Could you give me some pointers as to how to achieve this please? For example, in my Eclipse launch configuration, do I need to specify com.google.gwt.dev.GWTShell as the main class or is the standard com.google.gwt.dev.DevMode ok?

                I didn't find much specific documentation on the -noserver option, just this page: http://ukitech.blogspot.com/2008/05/gwtshell-arguments.html, so if you could give me a couple of clues I'd be really grateful.

                Thanks

                Comment


                  #9
                  Ok, I made some progress so I now have a simple application running within the context of the standard embedded Tomcat instance, but I'm experiencing troubles with RPC communication.

                  When I instantiate a RPCRequest within my client side application such as in the following sample

                  Code:
                  public class Simple implements EntryPoint
                  {
                  ...
                  	@Override
                  	public void onModuleLoad()
                  	{
                  		this.dynamicForm = new DynamicForm();
                  		this.textItem = new TextItem();
                  		this.button = new IButton();
                  		
                  		this.button.setTitle( "Click me!" );
                  		
                  		this.button.addClickHandler
                  		(
                  			new ClickHandler()
                  			{
                  				@Override
                  				public void onClick( final ClickEvent event )
                  				{
                  					final RPCRequest rpcRequest = new RPCRequest();
                  					final Map<String, String> data = new HashMap<String, String>();
                  					data.put( "transactionType", "requestDataSources" );
                  					rpcRequest.setData( data );
                  					RPCManager.sendRequest( rpcRequest );
                  				}
                  			}
                  		);
                  		
                  		this.dynamicForm.setFields( this.textItem );
                  		RootPanel.get().add( this.dynamicForm );
                  		RootPanel.get().add( this.button );
                  	}
                  I always receive a 404 error as shown below:

                  Code:
                  13:01:31.066 [ERROR] [simple] 13:01:31.052:XRP1:WARN:RPCManager:Transport error - HTTP code: 404 for URL: http://127.0.0.1:8888/war/simple/sc/IDACall, response: {operationId: "custom", clientContext: undef, context: Obj, transactionNum: 2, httpResponseCode: 404, httpResponseText: "<html><head><title>Apache Tomcat/5.5.23 ..."[1018], xmlHttpRequest: [object XMLHttpRequest], transport: "xmlHttpRequest", status: -90, clientOnly: undef, httpHeaders: Obj, isStructured: true, callbackArgs: null, results: Obj, data: "Transport error - HTTP code: 404 for URL..."[85]}
                  so it looks to me like it's trying to send the request to a URL ('sc/IDACall') which doesn't exist.

                  In my embedded Tomcat web.xml I have the following lines which registers my own custom IDACall servlet:

                  Code:
                  <servlet>
                  	<servlet-name>IDACall</servlet-name>
                  	<servlet-class>com.aln.database.CustomDataSourceServlet</servlet-class>
                  </servlet>
                  and this servlet is instantiated at the first RPC request from a jsp page so I'm not sure why the same doesn't happen when the request comes from my simple web app class.

                  If anyone has any ideas please let me know - I'd be really grateful.

                  Thanks

                  Comment


                    #10
                    Use Firebug to look at the paths. Most likely, you need to add "simple" to the path where you are registering the servlet, or a similar fix to make the paths match. See the sample projects and EE setup instructions, which discuss this.

                    Comment


                      #11
                      The 404 URL seems suspicious : http://127.0.0.1:8888/war/simple/sc/IDACall

                      The "war" portion seems superfluous.

                      Comment


                        #12
                        Hi, thanks for both replies Isomorphic and smartgwt.dev. You're both right that the path was the issue. Because I deployed [ok, copied ;-) ] the whole war directory to the embedded tomcat installation, I needed to change the declaration of isomorphicDir in simple.html to refer to <web root>/isomorphic and then at runtime the path that was generated was http://127.0.0.1:8888/isomorphic/IDACall which in turn meant that my (custom) IDACall servlet's handleRPCRequest was invoked.

                        It took a long time debugging on the server side to determine the root cause of a simple lack of understanding on my part, but now I'm really happy because I can develop everything in Java.

                        Thanks

                        Comment

                        Working...
                        X