gmane.comp.java.dwr.user

[dwr-users] Re: possible to use Spring EL within dwr.xml ?

David Marginian — 2013-05-22T21:43:09

And to clarify your post, you are not using dwr.xml you are using dwr tags
within your Spring context.


On Wed, May 22, 2013 at 3:38 PM, David Marginian <david-H55tQ8LTKd1xxXtqJ93Y6g< at >public.gmane.org>wrote:

[dwr-users] Re: possible to use Spring EL within dwr.xml ?

David Marginian — 2013-05-22T21:38:15

Todd, I think you answered your own question here.  That being said if you
need this to work you can probably take a look at how Spring handles
parsing expressions within xml and modify DWR's source to do something
similar.  If you can get this working and submit a patch that would be
great.

On Wed, May 22, 2013 at 2:14 PM, Todd Java <todd.java-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

[dwr-users] possible to use Spring EL within dwr.xml ?

Todd Java — 2013-05-22T20:14:43

Hi all,

Here is my basic environment:

DWR 3.0.0-RC3 + Spring 3.1.0
* DWR build is about 1 year old
* The value of "bamboo.build.number" in "dwr-version.properties" is empty
for some reason (but no longer a problem in the latest dev builds)

We have successfully integrated DWR and Spring, has been running happily in
our production environment for about 1 year.

I'm trying to figure-out if it's possible to use Spring EL (SPEL) within my
dwr.xml

I can use SPEL just fine within my applicationContext.xml, the SPEL syntax
is parsed and evaluated as expected.

However, when I try to use SPEL syntax in dwr.xml it is clearly not
interpreted. For example, here is a small test I did:
    <dwr:controller id="dwrController" debug="false">
        <dwr:config-param name="overridePath" value="#{1 == 1 ? 'good' :
'bad'}"/>
    </dwr:controller>

What I see in the DWR-generated js files (that correspond to my controller
classes) is the following:
    var p;

    p = {};
    p._path = '#{1 == 1 ? 'good' : 'bad'}';

So, the overridePath value is treated as a literal string instead of parsed
as SPEL syntax. If I change the overridePath value to "/foobar" it's
treated as a literal string, which is what I'd expect.

In case you're wondering, I'm trying to set the overridePath based on the
environment - our setup is quite different between QA and Production.

Sorry if I've made some careless error. I've been wrestling with this for a
few days and feel like I've tried everything.

Thanks for your help,
Todd

[dwr-users] Re: Dwr error on WAS 8.5

David Marginian — 2013-05-17T02:13:42

1) If you change the class you have exposed to not implement an 
interface, does the problem go away?

2) Would you be willing to download the DWR source, place a few 
breakpoints in the code 
(org.directwebremoting.impl.DefaultCreatorManager addCreator), and 
investigate this a bit?

On 05/16/2013 05:50 AM, T THRADINGHAM wrote:

[dwr-users] Dwr error on WAS 8.5

T THRADINGHAM — 2013-05-16T11:50:27

Hi guys,
I wonder if you can help me as I'm experiencing a strange issue with DWR, Spring and Websphere.
 
My setup currently is Websphere 7, Spring 2.5, Dwr 2. We are moving to Websphere 8.5. This causes us the dreaded crossDomainSessionSecurity issue - currently remedied by changing the dwr configuration setting to false as per the current guidelines - and everything is working as expected. 
At some stage we will probably upgrade to Dwr 3 and as we are undergoing a WAS change at the moment I decided to test this out. So I have downloaded Dwr 3 and included the jar in one of my applications. We have a number of apps using Dwr so we have no plan for major changes, but simple configuration changes are ok.
 
So, my setup now is Websphere 8.5, Dwr 3, Spring 2.5. 
When trying to access my app I am getting the following error thrown in the WAs logs -
 
[16/05/13 10:37:03:478 BST] 00000092 startup I org.directwebremoting.impl.StartupUtil logStartup Starting: DwrController v3.0.0-RC2-final-312 on IBM WebSphere Application Server/8.0 / JDK 1.6.0 from IBM Corporation at /Myapp
[16/05/13 10:37:03:587 BST] 00000092 startup E org.directwebremoting.impl.DefaultCreatorManager addCreator Javascript name MyAjaxHandler is used by 2 classes (com.chubb.ezer.myapp.web.ajax.handlers.MyAjaxHandlerImpl and BeanCreator[MyAjaxHandler])
[16/05/13 10:37:03:587 BST] 00000092 DwrController E org.directwebremoting.spring.DwrController afterPropertiesSet init failed
java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: Duplicate name found. See logs for details.
at org.directwebremoting.spring.SpringConfigurator.configure(SpringConfigurator.java:151)
at org.directwebremoting.impl.StartupUtil.configure(StartupUtil.java:702)
at org.directwebremoting.spring.DwrController.afterPropertiesSet(DwrController.java:200)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1368)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1334)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
 
As far as I can tell this error is being caused by the dwr configuration of the javascript files and I am unable to resolve this.I have looked everywhere I can and am yet to find a resolution. Could you please help?
 
Here are the code snippets of our setup 
 
web.xml<servlet><servlet-name>dwr</servlet-name><servlet-class>org.directwebremoting.spring.DwrSpringServlet</servlet-class><init-param><param-name>debug</param-name><param-value>true</param-value></init-param></servlet><servlet-mapping><servlet-name>dwr</servlet-name><url-pattern>/dwr/*</url-pattern> 
 dwrsetupbeans.xml
 <beansxmlns="http://www.springframework.org/schema/beans"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:dwr="http://www.directwebremoting.org/schema/spring-dwr"xmlns:aop="http://www.springframework.org/schema/aop"http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-2.0.xsd
http://www.directwebremoting.org/schema/spring-dwr
http://www.directwebremoting.org/schema/spring-dwr-3.0.xsd"xsi:schemaLocation="http://www.springframework.org/schema/beans><beanid="myAjaxHandler"class="com.chubb.ezer.myapp.web.ajax.handlers.MyAjaxHandlerImpl"><aop:scoped-proxy/><propertyname="myService"ref="myService"/><propertyname="requestBuilder"ref="requestBuilder"/><dwr:remotejavascript="MyAjaxHandler"><dwr:includemethod="doSave"/></dwr:remote></bean><dwr:controllerid="dwrController"debug="true"></dwr:controller> somemappings.xml
 <beansxmlns="http://www.springframework.org/schema/beans"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"http://www.springframework.org/schema/beans/spring-beans-2.5.xsd"xsi:schemaLocation="http://www.springframework.org/schema/beans>using two mapping handlers: 
1st will map to a bean matching the URL 
2nd will pass anything not picked up by the 1st to a DWR controller 
--><!-- <beanname="urlMapping2"class="org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping"><propertyname="order"><value>0</value></property></bean><beanname="urlMapping"class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"><propertyname="lazyInitHandlers"><value>true</value></property><propertyname="mappings"><props><propkey="/*">dwrController</prop></props></property></bean> 
excerpt from a root jsp file
 <!
<
<DOCTYPEHTMLPUBLIC"-//W3C//DTD HTML 4.01 Transitional//EN">html>head><metahttp-equiv="Content-Type"content="text/html; charset=ISO-8859-1"><metahttp-equiv="expires"content="${today}"><linkhref="${ctx}/style/myGeneral.css"rel="stylesheet"type="text/css"><scriptsrc="${ctx}/javascript/h1Section.js"></script><scriptsrc='${ctx}/dwr/engine.js'></script><scriptsrc='${ctx}/dwr/util.js'></script><scriptsrc='${ctx}/dwr/interface/MyAjaxHandler.js'></script> 
excerpt from the java objects
 public
}interfaceMyAjaxHandler {publicString doSave(String arg);public
MyService 
//code here
}
　
　classMyAjaxHandlerImpl extendsAbstractAjaxHandler implementsMyAjaxHandler {myService;privateRequestBuilder requestBuilder;publicString doSave(String arg) {return(arg);As you can see the objects exposed to Dwr are implementations of an interface. 
I believe that should cover all the various components involved and hope someone may be able to point me to a solution. Please remember that this exact same setup works with Dwr2, Spring2.5 and WAS 8.5 but with the added cross Domain session secuity setting.
Regards
Tim<dwr:configuration></dwr:configuration></servlet-mapping>

[dwr-users] Re:

David Marginian — 2013-05-14T23:09:35

The NPE is being thrown on this line:
return 
LocalUtil.classForName(moduleConfig.findFormBeanConfig(formBean).getType());

It looks like the formBean can't be found (best guess).

If you had everything working I would suggest back-tracking your steps.

On 05/14/2013 04:08 PM, Fordemo Only wrote:

[dwr-users]

Fordemo Only — 2013-05-14T22:08:33

Hello
I re-deployed an app with changes, none of which I believed 
affected dwr and I am getting the error below.  Works perfectly in the 
previous environment.  Using 2.0.10, same error when deployed to Tomcat 
6.0.29 and Tomcat 6.0.37.  DWR is in \WEB-INF\lib I am nonplused.  I 
have nothing else to try.  tia.

error snipped
0    
[http-8080-1] ERROR org.directwebremoting.impl.DefaultCreatorManager  
error - Error loading class for creator 'StrutsCreator[pojo00]'.
java.lang.NullPointerException
    at org.directwebremoting.struts.StrutsCreator.getType(StrutsCreator.java:121)
    at org.directwebremoting.impl.DefaultCreatorManager.addCreator(DefaultCreatorManager.java:118)
    at
 org.directwebremoting.impl.DefaultCreatorManager.addCreator(DefaultCreatorManager.java:100)
    at org.directwebremoting.impl.DwrXmlConfigurator.loadCreate(DwrXmlConfigurator.java:274)
    at org.directwebremoting.impl.DwrXmlConfigurator.loadAllows(DwrXmlConfigurator.java:224)
    at org.directwebremoting.impl.DwrXmlConfigurator.configure(DwrXmlConfigurator.java:170)
    at org.directwebremoting.impl.ContainerUtil.configureFromDefaultDwrXml(ContainerUtil.java:264)
    at org.directwebremoting.impl.ContainerUtil.configureContainerFully(ContainerUtil.java:421)
    at org.directwebremoting.servlet.DwrServlet.init(DwrServlet.java:79)
    at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173)
...

drw.xml snipped
<!DOCTYPE dwr PUBLIC
    "-//GetAhead Limited//DTD Direct Web
 Remoting 2.0//EN"
    "http://directwebremoting.org/schema/dwr20.dtd">

    <dwr>
      <allow>
        <create creator="struts" javascript="pojo00" scope="session">
          <param name="formBean" value="ccAuth13_genericForm_FBO_dwr"/>
          <include method="makePOJO" />
          <include method="phaseTwoData" />
          <include method="reportWriter00" />
...

[dwr-users] Re: How disable escaped single quotes in JSON/JSONP response with dwr-3.0.0.rc2 and jsonpEnabled

David Marginian — 2013-05-08T23:36:28

I realize I mistakenly responded to Josh directly.  If anyone else is 
interested in this we have created an issue for it - 
http://directwebremoting.org/jira/browse/DWR-602.  Please follow the 
comments there, this issue was just resolved and the fix will be 
available in RC3 or bamboo builds 514 and up.

On 05/07/2013 10:40 AM, Josh Sents wrote:

[dwr-users] Re: Memory Leak in Clock Demo DWR 2.0.5 and IE 9

Mike Wilson — 2013-05-08T14:15:30

Ok, thanks for testing, Mark. I still find it strange that IE is leaking
with the script tag approach. I'll keep an eye out for this in our work on
http://bugs.directwebremoting.org/jira/browse/DWR-576.
 
Best regards
Mike
 
Mark Priest wrote:

Mike, 

I didn't see any improvement in the leak with your script tag approach.  It
was still leaking about 6.4 mb/hr.   using your script tag approach.  The
memory is reclaimed when I refresh the browser.

It's worth mentioning that this leak isn't likely to be a problem for a lot
of people.  In our case, customers want our app to run for a week at a time
or longer without refreshing the page so any leak starts to be a problem.  I
think this is probably a rare requirement, however.  Also, if we could use
Chrome or Firefox I don't think we would see any leak.


On Sun, May 5, 2013 at 6:50 AM, Mike Wilson <mikewse-PkbjNfxxIARBDgjK7y7TUQ< at >public.gmane.org> wrote:



Thanks for testing. Both JS functions trigger closures internally in IE so
it might be those that IE have a hard time cleaning up. They don't have a
great track record in that department ;-)
 
It might be worth trying something that doesn't trigger any closures at all.
I'm successfully running the following in my local env:
 
dwr.engine._eval = function(script) {
    if (script == null) return null;
    if (script == "") { dwr.engine._debug("Warning: blank script", true);
return null; }
    var elem = document.createElement("script");
    elem.text = script;
    var head = document.getElementsByTagName("head")[0];
    head.appendChild(elem);
    head.removeChild(elem);
};
 
I haven't had time to test a lot of browsers yet, or do any long running
resource tests. It would be great if you could try to see what (if any)
difference it makes for you?
 
Best regards
Mike
 
Mark Priest wrote:

Mike/David,

Unfortunately, I didn't see any improvement using execScript.  That function
is used to do an eval in the global scope and is intended to be used to load
long-lived scripts dynamically.

My coworker tried the approach of doing the eval in an iframe as suggested
in the Microsoft knowledge base article I referenced.  This was their
suggestion for use with IE 7.   The leak was reduced to 40% of the leak we
see using eval in the parent.   However,  the memory does not get reclaimed
in that case until you close the browser.   When doing the eval without the
iframe the memory is reclaimed when the page is refreshed or when you browse
to a new page.

We are still planning to go down the road of removing eval altogether and
sending JSON back to the browser rather than executable JavaScript.

-Mark

On May 3, 2013, at 11:18 AM, David Marginian <david-H55tQ8LTKd1xxXtqJ93Y6g< at >public.gmane.org> wrote:



Just an FYI guys, I tried replacing our _eval last night with a version that
uses the execScript and all our tests pass, etc.  So if it fixes the memory
leak it will be a good fix to get in.



On Fri, May 3, 2013 at 9:15 AM, Mike Wilson <mikewse-PkbjNfxxIARBDgjK7y7TUQ< at >public.gmane.org> wrote:



Great find, thanks Mark!
BTW, in my tests I got much lower memory increase than 8MB/hr so it seems it
can vary depending on some environmental factor.
Looking forward to your execScript tests! Another alternative could be to
add an inline <script> tag containing the script through the DOM.
 
Best regards
Mike
 
Mark Priest wrote:

A simpler way to demonstrate that the leak disappears when removing eval()
is to run the clock demo but edit the engine.js like so: 


dwr.engine._eval = function(script) {
  if (script == null) return null;
  if (script == "") { dwr.engine._debug("Warning: blank script", true);
return null; }
  // dwr.engine._debug("Exec: [" + script + "]", true);
  
  //return eval(script);
  // hard-code the response so we don't call eval
  var batchNum = dwr.engine._nextBatchId - 1;
  dwr.util.setValue("clockDisplay", "" + batchNum);
  dwr.engine._remoteHandleCallback("" + batchNum,'0',0);


};


If you do that then you can test by doing this:


1. Hit the clock demo page and start the clock 
2. Close the browser 
3. Hit the clock demo page again and see the batch ids being printed


That is necessary because I changed _eval() to just print the batch id every
time rather than eval the expression (and print the server date/time) and
the first time that gets messed up by the call to start the clock.  After
the first few minutes the memory usage stabilizes and it leaks very little -
maybe 37 kb/hr compared to 8 mb/hr in the unedited demo.

[dwr-users] Re: Incomplete reply from server in Chrome - when using location.href or window.parent.location

Mike Wilson — 2013-05-08T14:17:24

Does the last solution seem to work well, Aneesh?
Best regards
Mike 

Aneesh Vijendran wrote:

[dwr-users] How disable escaped single quotes in JSON/JSONP response with dwr-3.0.0.rc2 and jsonpEnabled

Josh Sents — 2013-05-07T16:40:33

I have been using DWR-native remote inside our web application.It works 
awesome! Now I am creating an API for an external client within the same 
application. The client has required that I return valid JSON response.I 
have enabled JSON/JSONP and I get the response back from the server with 
the expected data.The problem is that the JSON does not pass JSON 
validation.Here is a sample site that validates a JSON string 
http://jsonlint.com/ .I think the only issue is that the String fields 
have single quotes escaped.

Is there a way to disable escaping for the JSON/JSONP remote responses 
only and leave the escaping enabled DWR-native remote?

Thanks

Josh

[dwr-users] Re: Memory Leak in Clock Demo DWR 2.0.5 and IE 9

Mark Priest — 2013-05-06T18:15:30

Mike,

I didn't see any improvement in the leak with your script tag approach.  It
was still leaking about 6.4 mb/hr.   using your script tag approach.  The
memory is reclaimed when I refresh the browser.

It's worth mentioning that this leak isn't likely to be a problem for a lot
of people.  In our case, customers want our app to run for a week at a time
or longer without refreshing the page so any leak starts to be a problem.
 I think this is probably a rare requirement, however.  Also, if we could
use Chrome or Firefox I don't think we would see any leak.


On Sun, May 5, 2013 at 6:50 AM, Mike Wilson <mikewse-PkbjNfxxIARBDgjK7y7TUQ< at >public.gmane.org> wrote:

[dwr-users] Test

David Marginian — 2013-05-06T11:59:08

This is a test message.

[dwr-users] Re: Memory Leak in Clock Demo DWR 2.0.5 and IE 9

Mike Wilson — 2013-05-05T10:50:55

Thanks for testing. Both JS functions trigger closures internally in IE so
it might be those that IE have a hard time cleaning up. They don't have a
great track record in that department ;-)
 
It might be worth trying something that doesn't trigger any closures at all.
I'm successfully running the following in my local env:
 
dwr.engine._eval = function(script) {
    if (script == null) return null;
    if (script == "") { dwr.engine._debug("Warning: blank script", true);
return null; }
    var elem = document.createElement("script");
    elem.text = script;
    var head = document.getElementsByTagName("head")[0];
    head.appendChild(elem);
    head.removeChild(elem);
};
 
I haven't had time to test a lot of browsers yet, or do any long running
resource tests. It would be great if you could try to see what (if any)
difference it makes for you?
 
Best regards
Mike
 
Mark Priest wrote:

Mike/David,

Unfortunately, I didn't see any improvement using execScript.  That function
is used to do an eval in the global scope and is intended to be used to load
long-lived scripts dynamically.

My coworker tried the approach of doing the eval in an iframe as suggested
in the Microsoft knowledge base article I referenced.  This was their
suggestion for use with IE 7.   The leak was reduced to 40% of the leak we
see using eval in the parent.   However,  the memory does not get reclaimed
in that case until you close the browser.   When doing the eval without the
iframe the memory is reclaimed when the page is refreshed or when you browse
to a new page.

We are still planning to go down the road of removing eval altogether and
sending JSON back to the browser rather than executable JavaScript.

-Mark

On May 3, 2013, at 11:18 AM, David Marginian <david-H55tQ8LTKd1xxXtqJ93Y6g< at >public.gmane.org> wrote:



Just an FYI guys, I tried replacing our _eval last night with a version that
uses the execScript and all our tests pass, etc.  So if it fixes the memory
leak it will be a good fix to get in.



On Fri, May 3, 2013 at 9:15 AM, Mike Wilson <mikewse-PkbjNfxxIARBDgjK7y7TUQ< at >public.gmane.org> wrote:



Great find, thanks Mark!
BTW, in my tests I got much lower memory increase than 8MB/hr so it seems it
can vary depending on some environmental factor.
Looking forward to your execScript tests! Another alternative could be to
add an inline <script> tag containing the script through the DOM.
 
Best regards
Mike
 
Mark Priest wrote:

A simpler way to demonstrate that the leak disappears when removing eval()
is to run the clock demo but edit the engine.js like so: 


dwr.engine._eval = function(script) {
  if (script == null) return null;
  if (script == "") { dwr.engine._debug("Warning: blank script", true);
return null; }
  // dwr.engine._debug("Exec: [" + script + "]", true);
  
  //return eval(script);
  // hard-code the response so we don't call eval
  var batchNum = dwr.engine._nextBatchId - 1;
  dwr.util.setValue("clockDisplay", "" + batchNum);
  dwr.engine._remoteHandleCallback("" + batchNum,'0',0);


};


If you do that then you can test by doing this:


1. Hit the clock demo page and start the clock 
2. Close the browser 
3. Hit the clock demo page again and see the batch ids being printed


That is necessary because I changed _eval() to just print the batch id every
time rather than eval the expression (and print the server date/time) and
the first time that gets messed up by the call to start the clock.  After
the first few minutes the memory usage stabilizes and it leaks very little -
maybe 37 kb/hr compared to 8 mb/hr in the unedited demo.

[dwr-users] Re: Memory Leak in Clock Demo DWR 2.0.5 and IE 9

Mark Priest — 2013-05-04T14:07:51

Mike/David,

Unfortunately, I didn't see any improvement using execScript.  That function is used to do an eval in the global scope and is intended to be used to load long-lived scripts dynamically.

My coworker tried the approach of doing the eval in an iframe as suggested in the Microsoft knowledge base article I referenced.  This was their suggestion for use with IE 7.   The leak was reduced to 40% of the leak we see using eval in the parent.   However,  the memory does not get reclaimed in that case until you close the browser.   When doing the eval without the iframe the memory is reclaimed when the page is refreshed or when you browse to a new page.

We are still planning to go down the road of removing eval altogether and sending JSON back to the browser rather than executable JavaScript.

-Mark

On May 3, 2013, at 11:18 AM, David Marginian <david-H55tQ8LTKd1xxXtqJ93Y6g< at >public.gmane.org> wrote:

[dwr-users] Re: Memory Leak in Clock Demo DWR 2.0.5 and IE 9

David Marginian — 2013-05-03T15:18:49

Just an FYI guys, I tried replacing our _eval last night with a version
that uses the execScript and all our tests pass, etc.  So if it fixes the
memory leak it will be a good fix to get in.


On Fri, May 3, 2013 at 9:15 AM, Mike Wilson <mikewse-PkbjNfxxIARBDgjK7y7TUQ< at >public.gmane.org> wrote:

[dwr-users] Re: Memory Leak in Clock Demo DWR 2.0.5 and IE 9

Mike Wilson — 2013-05-03T15:15:56

Great find, thanks Mark!
BTW, in my tests I got much lower memory increase than 8MB/hr so it seems it
can vary depending on some environmental factor.
Looking forward to your execScript tests! Another alternative could be to
add an inline <script> tag containing the script through the DOM.
 
Best regards
Mike
 
Mark Priest wrote:

A simpler way to demonstrate that the leak disappears when removing eval()
is to run the clock demo but edit the engine.js like so: 


dwr.engine._eval = function(script) {
  if (script == null) return null;
  if (script == "") { dwr.engine._debug("Warning: blank script", true);
return null; }
  // dwr.engine._debug("Exec: [" + script + "]", true);
  
  //return eval(script);
  // hard-code the response so we don't call eval
  var batchNum = dwr.engine._nextBatchId - 1;
  dwr.util.setValue("clockDisplay", "" + batchNum);
  dwr.engine._remoteHandleCallback("" + batchNum,'0',0);


};


If you do that then you can test by doing this:


1. Hit the clock demo page and start the clock 
2. Close the browser 
3. Hit the clock demo page again and see the batch ids being printed


That is necessary because I changed _eval() to just print the batch id every
time rather than eval the expression (and print the server date/time) and
the first time that gets messed up by the call to start the clock.  After
the first few minutes the memory usage stabilizes and it leaks very little -
maybe 37 kb/hr compared to 8 mb/hr in the unedited demo.

[dwr-users] Re: Memory Leak in Clock Demo DWR 2.0.5 and IE 9

Mark Priest — 2013-05-03T00:43:41

Yes, I do have time right now.  I will look into the jquery approach.

On May 2, 2013, at 7:58 PM, David Marginian <david-H55tQ8LTKd1xxXtqJ93Y6g< at >public.gmane.org> wrote:

[dwr-users] Re: Memory Leak in Clock Demo DWR 2.0.5 and IE 9

David Marginian — 2013-05-02T23:58:57

Thanks Mark.  I took a look at JQuery's code and I noticed they use 
execScript instead of eval for IE clients.  This may be something to 
look into.  Do you have some time to experiment with this?

On 05/02/2013 05:41 PM, Mark Priest wrote:

[dwr-users] Re: Memory Leak in Clock Demo DWR 2.0.5 and IE 9

Mark Priest — 2013-05-02T23:41:50

A simpler way to demonstrate that the leak disappears when removing eval()
is to run the clock demo but edit the engine.js like so:

dwr.engine._eval = function(script) {
  if (script == null) return null;
  if (script == "") { dwr.engine._debug("Warning: blank script", true);
return null; }
  // dwr.engine._debug("Exec: [" + script + "]", true);

  //return eval(script);
  // hard-code the response so we don't call eval
  var batchNum = dwr.engine._nextBatchId - 1;
  dwr.util.setValue("clockDisplay", "" + batchNum);
  dwr.engine._remoteHandleCallback("" + batchNum,'0',0);

};

If you do that then you can test by doing this:

1. Hit the clock demo page and start the clock
2. Close the browser
3. Hit the clock demo page again and see the batch ids being printed

That is necessary because I changed _eval() to just print the batch id
every time rather than eval the expression (and print the server date/time)
and the first time that gets messed up by the call to start the clock.
 After the first few minutes the memory usage stabilizes and it leaks very
little - maybe 37 kb/hr compared to 8 mb/hr in the unedited demo.

On Thu, May 2, 2013 at 3:29 PM, Mark Priest <mark.priest-bdq14YP6qtRg9hUCZPvPmw< at >public.gmane.org>wrote:

[dwr-users] Re: SVN Tag or revision for 2.0.10

David Marginian — 2013-05-02T21:46:51

Mark, generally I tag each release. But it appears I have failed to do 
that for the 2.x branch since 2.0.8.  There are very few changes in 
2.0.9 and 2.0.10.  And there are probably even fewer changes from 2.0.10 
to trunk.  Let me take a look and see where we are and I may be able to 
push out a 2.0.11 and tag it (I have been planning on doing this soon 
anyway).

On 05/02/2013 03:13 PM, Mark Priest wrote: