Announcement

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

    Upgrade to SmartGWT 4.1 LGPL - Problems (full steps outlined)

    Hi there.

    I have gone through every step I know to do and that I have found in the Installation, FAQ and Forums. I need help to know what I have missed during the upgrade process.

    I have provided as much information as I could think and gather.

    NOTE: I did NOT go through any process to upgrade or change our custom Skin. I wasn't sure if that was necessary - or what I should do for that if it is necessary.

    ISSUES:
    ----------
    Encountered 2 issues that are currently visible / known after upgrading (which did not exist previous to the upgrade).

    A) There a couple of LinkItem objects that displayed just fine previously but now, instead of showing the text, it shows the event contents: "javascript:void".

    Images attached for example:
    FilteredSearchBeforeUpdate.png
    FilteredSearchAfterUpdate.png


    B) Several REST calls return back fine and the display updates no problem. After the upgrade, there is one call to refine a search and two things happen:

    i) The REST call returns successfully (status = 200) BUT the data is NOT returned/updated and something hangs.

    ii) The loading / waiting dialog does NOT close and the data does not refresh on the screen....almost as though the page is frozen.

    There are NO errors logged in the regular console, the Developer Console (ISC) or in the browser console.

    Files attached (Firebug Log):
    firebuglog-firstload-of-application.txt (when app loads - all ok)
    firebuglog-firstsearch.txt (first search - all ok)
    firebuglog-filteredsearch-page-hangs.txt (this is where it hangs)



    SmartGWT Version (as shown in Developer Console):
    ----------------------------------------------------------------
    SmartClient Version: v9.1p_2014-03-22/LGPL Development Only (built 2014-03-22)

    Browser:
    -------------
    Firefox 24

    In this post, I have outlined all the steps I know to mention in the process of going through a SmartGWT upgrade (existing project) to 4.1.

    Project Configuration:
    ---------------------------

    Eclipse Kepler
    Google Web Toolkit v. 2.6.0
    Java / JDK 1.7
    SmartGWT 4.1

    STEPS FOR UPGRADE (SmartGWT LGPL):
    ------------------------------------------------

    1. In moduleName.gwt.xml file, removed imports of any GWT themes, leaving only the import of com.google.gwt.user.User. But kept project specific imports.

    2, Copied the smartgwt.jar and smartgwt-skins.jar from the smartgwt-4.1p folder to my classpath (libs folder) - replacing the previous version of those files.

    3. I did not see any other jars from any of the sample projects to copy over.

    4. Updated modulename.gwt.xml with this content:

    Code:
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit 2.3.0//EN" "http://google-web-toolkit.googlecode.com/svn/tags/2.3.0/distro-source/core/src/gwt-module.dtd">
    <module rename-to="XIT">
    	
        <inherits name='com.google.gwt.user.User'/>
        <inherits name="com.smartgwt.tools.SmartGwtTools"/>
    	<inherits name="com.smartgwt.SmartGwtNoScript"/>
        <inherits name="com.smartgwt.SmartGwt"/>
    	<inherits name="com.google.gwt.i18n.I18N"/>
    	<inherits name="com.smartclient.theme.enterprise.EnterpriseResources" /> 	
    	
    	<source path="views" />
    	<source path="util" />
    	<source path="ds" />
    	<source path="viewmodels" />
    	
    	<inherits name="com.amita.aframe.gwt.management.Management"/>
    	
    	<entry-point class="com.amita.xit.views.XITClient" />
    	
    	<extend-property name="locale" values="fr" />
    	
    	<!--  For testing only - uncomment to allow all browser / language permutations to be compiled--> 
        <!-- <set-property name="user.agent" value="gecko1_8" />-->
    	
    </module>
    5. Modified the bootstrap HTML file (modulename.html) to set the isomorphicDir:

    Code:
         <script>var isomorphicDir = "modulename/sc/";</script>
    Full contents of bootstrap HTML:

    Code:
    <!DOCTYPE html>
    <html>
      <head>
    	  
        <style type="text/css">
    		<!-- SOME CUSTOM STYLING FOR OUR PROJECT -->
        </style>
    
        <meta http-equiv="content-type" content="text/html; charset=UTF-8">
        <script>var isomorphicDir = "XIT/sc/";</script>
        <script type="text/javascript" language="javascript" src="XIT/XIT.nocache.js"></script>
        <script type="text/javascript" language="javascript" src="skins/AmitaSimple/load_skin.js"></script>
        <title>XIT</title>
    
      </head>
    
      <body>
        
        <iframe src="javascript:''" id="__gwt_historyFrame" tabIndex='-1' style="position:absolute;width:0;height:0;border:0"></iframe>
    
        <iframe height="0" name="hidden_frame">  
    	 </iframe>
    	
      </body>
    </html>

    6. Could not find a copy of war/WEB-INF/classes/log4j.config.xml in any of the sample projects. Did not create one. Is this necessary for an LGPL project?

    7. Could not find a copy of war/WEB-INF/classes/server.properties in any of the sample projects. Did not create one. Is this necessary for an LGPL project?

    8. Full contents of web.xml

    Code:
    <?xml version="1.0" encoding="utf-8"?>
    <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    		xmlns="http://java.sun.com/xml/ns/javaee"
    		xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    		xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
    							http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" 
    		version="2.5">
       
    	<context-param>
    		<param-name>contextConfigLocation</param-name>
    		<param-value>/WEB-INF/applicationContext.xml</param-value>
    	</context-param>
    	
    	<session-config>
        	<session-timeout>20</session-timeout>
    	</session-config>
       
    	<filter>
            <filter-name>springSecurityFilterChain</filter-name>
            <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
        </filter>
    
        <filter-mapping>
          <filter-name>springSecurityFilterChain</filter-name>
          <url-pattern>/*</url-pattern>
        </filter-mapping>
    	
       	<listener>
    		<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    	</listener>
    
    	<!--  create a dispatcher servlet named "rest", it will configure itself with rest-servlet.xml -->   
    	<servlet>
    		<servlet-name>rest</servlet-name>
    		<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    		<load-on-startup>1</load-on-startup>
    	</servlet>
    	
    	<servlet-mapping>
    		<servlet-name>rest</servlet-name>
    		<url-pattern>/service/*</url-pattern>		
    	</servlet-mapping>
    
       	<welcome-file-list>
           <welcome-file>XITClient.html</welcome-file>
       	</welcome-file-list>
       
    </web-app>
    9. Could not find a copy of war/WEB-INF/iscTaglib.xml in any of the sample projects. Did not create one. Is this necessary for an LGPL project?

    10. Other Troubleshooting Steps:

    - Changed JDK in Eclipse from 1.6 and then back to 1.7 (according to the FAQ as one measure to take)

    - Removed all other project contents that used previous versions of SmartGWT

    - Double checked (in Firebug Net window) to make sure that only the proper JS files are being loaded.


    NOTE - Net Display of all js files loaded on load of first page:

    [17:01:05.940] GET http://127.0.0.1:8888/XIT/XIT.nocache.js [HTTP/1.1 200 OK 3ms]
    [17:01:05.940] GET http://127.0.0.1:8888/skins/AmitaSimple/load_skin.js [HTTP/1.1 200 OK 4ms]
    [17:01:05.941] GET http://127.0.0.1:8888/XIT/sc/modules/ISC_Core.js [HTTP/1.1 200 OK 11ms]
    [17:01:05.941] GET http://127.0.0.1:8888/XIT/sc/modules/ISC_Foundation.js [HTTP/1.1 200 OK 6ms]
    [17:01:05.942] GET http://127.0.0.1:8888/XIT/sc/modules/ISC_Containers.js [HTTP/1.1 200 OK 12ms]
    [17:01:05.942] GET http://127.0.0.1:8888/XIT/sc/modules/ISC_Grids.js [HTTP/1.1 200 OK 234ms]
    [17:01:05.943] GET http://127.0.0.1:8888/XIT/sc/modules/ISC_Forms.js [HTTP/1.1 200 OK 171ms]
    [17:01:05.943] GET http://127.0.0.1:8888/XIT/sc/modules/ISC_RichTextEditor.js [HTTP/1.1 200 OK 14ms]
    [17:01:05.944] GET http://127.0.0.1:8888/XIT/sc/modules/ISC_Calendar.js [HTTP/1.1 200 OK 18ms]
    [17:01:05.944] GET http://127.0.0.1:8888/XIT/sc/modules/ISC_DataBinding.js [HTTP/1.1 200 OK 20ms]
    [17:01:05.945] GET http://127.0.0.1:8888/XIT/sc/skins/Enterprise/load_skin.js [HTTP/1.1 200 OK 21ms]
    [17:01:06.535] GET http://127.0.0.1:8888/XIT/sc/skins/Enterprise/skin_styles.css [HTTP/1.1 200 OK 4ms]
    Attached Files

    #2
    It's good to see an attempt to provide a bunch of detail about the environment and upgrade process, but unfortunately it's not really the relevant detail, and no one can really help when you provide only screenshots of a misbehaving application with totally unknown code.

    The only thing we can help with is - yes - those files do not apply to LGPL.

    Comment


      #3
      Thanks for the quick reply!

      The reason I hadn't supplied code is because the code was working fine previous to the upgrade (and still works in the environment running 3.1). So, I went with the assumption that it is something wrong with the way I did the upgrade.

      I was really hoping to have validation of the proper steps of the upgrade process I went through.

      For the LinkItem the relevant code is:

      Code:
      private final LinkItem linkItem = new LinkItem();
      
      linkItem.setTextBoxStyle("linkItem");
      linkItem.setValue(Constants.LABEL_HIDE_FILTERS); // Constants.LABEL_HIDE_FILTERS = Hide Filters
      
      // Add to containing form
      linkForm.setFields(linkItem);
      There is other code (i.e. a ClickHandler) but the issue on this is simply the display of the link on first load.


      Naturally, the code for the Search execution is more involved. Again, my thought is if that I can make sure the upgrade process was correct and it is still an issue I can perhaps create a separate ticket for that one...?

      I am willing to supply whatever is necessary to help validate the upgrade.

      Thanks again!

      Comment


        #4
        The upgrade steps you listed all sound fine.

        You did not list clearing your GWT unitcache, clearing your browser cache, re-running a GWT compile, restarting your IDE and other steps that are typical when troubleshooting an upgrade.

        Bigger picture, what people need to help is the same every time - a way to reproduce the problem.

        Comment


          #5
          Yes, I did perform all those steps in terms of clearing out caches.

          Ok, I’ll start with just the link item not generating properly. I supplied the code used above. Two environments are identical in terms of the code base (zero changes). Here is how the link item was generated…

          Generated in environment using 3.1

          <a id="isc_LinkItem_10$20j" href="javascript:void" target="javascript" tabindex="1563" onclick="if(window.isc_LinkItem_10) return isc_LinkItem_10.$30i(event);" $9a="$9d">Hide Filters</a>

          Generated in environment using 4.1

          <a id="isc_LinkItem_10$20j" href="javascript:void" target="javascript" tabindex="1563" onclick="if(window.isc_LinkItem_10) return isc_LinkItem_10.$30i(event);">javascript:void</a>


          Both using the exact same code.

          Also to be sure, I output the value of Constants.LABEL_HIDE_FILTERS using GWT.log and it does evaluate to the proper text in both cases.

          I am not sure what else to provide or to look at to get to the bottom of this. Any ideas?

          Thanks!

          Comment


            #6
            Any ideas?
            Yup!

            Bigger picture, what people need to help is the same every time - a way to reproduce the problem.
            Just try out LinkItem and you'll find that it is not out-and-out broken for the basic use case your code shows, then you can try to figure out how to reproduce the problem you're having in your app.

            Comment


              #7
              Ok, at the risk of over extending my welcome....

              I found the offending code.

              My LinkItem is set as a Form Field inside a Form.

              I created a test LinkItem and duplicated it exactly as the one I am having trouble with. The test LinkItem displayed perfectly right up until I added the click handler:

              Code:
              testItem.addClickHandler(new com.smartgwt.client.widgets.form.fields.events.ClickHandler() {
              			
              	@Override
              	public void onClick(com.smartgwt.client.widgets.form.fields.events.ClickEvent event) {
              
              				
              
              				
              	}
              });
              This is not a problem in 3.1 but is in 4.1. Am I implementing this incorrectly for the new build? If I comment out the click handler, the link displays properly. Note that there was logic in the handler but it made no difference for the purpose of this test case whether that code existed or not...it is simply the existence of the ClickHandler as I have it inside a form.

              The link is added to the form via: form.setFields(...)

              The ClickHandler is fully qualified so as not to implement the com.smartgwt.client.widgets.events.ClickHandler (because it is inside a form).

              If this is still not enough to get help on this, I will stop asking.

              Thanks again for your help and time.

              Comment


                #8
                This is getting repetitive, but again, this is an issue that arises in your application.

                We have no idea what settings you may have applied, or what incorrect usage you may have, separate from the code you've shown, that you have not yet mentioned.

                What we do know is that the documented usage of LinkItem is working great in automated tests and for all other users that have upgraded to 4.1.

                So - it may seem repetitive - but again what we need is a minimal, ready-to-run test case that reproduces a framework issue. Nothing else is actionable.

                Comment

                Working...
                X