Picon

[dwr-users] Re: Multiple dwr.xml files

Solved!! 
Just adding "/" before "WEB-INF". 
Thank you very much David.

--
View this message in context: http://dwr.2114559.n2.nabble.com/Multiple-dwr-xml-files-tp7239893p7242389.html
Sent from the DWR - Users mailing list archive at Nabble.com.

peddi satish | 3 Feb 03:02
Picon
Favicon

[dwr-users] dwr caching

Is there a way to implement caching of generated .js files on browser? can i find a sample if possible?

I have following configured in dwr.xml

        <create creator="new" javascript="SampleAjaxAction">
            <param name="class" value="com.org.ajax.SampleAjaxAction"/>
        </create>


It has generated SampleAjaxAction.js file, question is for each request this SampleAjaxAction.js file is getting loaded into browser, instead is there a caching mechanism so its once loaded into browser cache and doesn't reload upon subsequent requests.

Thanks,
Satish
David Marginian | 3 Feb 13:56

[dwr-users] Re: dwr caching

The interface scripts are static and should be cached by your browser.  
You can see this by going to our examples and using the Network tab in 
Firebug.  Here is a screenshot, note the 138.6 from cache, if you do 
this and then select the interface script and then go to the cache tab 
you will see that it has been cached:

On 02/02/2012 07:02 PM, peddi satish wrote:
> Is there a way to implement caching of generated .js files on browser? 
> can i find a sample if possible?
>
> I have following configured in dwr.xml
>
> <create creator="new" javascript="SampleAjaxAction">
> <param name="class" value="com.org.ajax.SampleAjaxAction"/>
> </create>
>
>
> It has generated SampleAjaxAction.js file, question is for each 
> request this SampleAjaxAction.js file is getting loaded into browser, 
> instead is there a caching mechanism so its once loaded into browser 
> cache and doesn't reload upon subsequent requests.
>
> Thanks,
> Satish

deb | 3 Feb 10:28
Picon

[dwr-users] DWR request sent twice

Hi,
Actually I had the problem when using jetty-7.6.0-RC3 or previous versions,
but when ever EOFException occurs dwr request is received twice at server.
The following is that exception:
*Nov 15, 2011 4:43:18 PM org.directwebremoting.dwrp.BaseCallHandler
marshallException
WARNING: Exception while processing batch*
org.eclipse.jetty.io.RuntimeIOException: org.eclipse.jetty.io.EofException
        at
org.eclipse.jetty.io.UncheckedPrintWriter.setError(UncheckedPrintWriter.java:107)
        at
org.eclipse.jetty.io.UncheckedPrintWriter.write(UncheckedPrintWriter.java:280)
        at
org.eclipse.jetty.io.UncheckedPrintWriter.write(UncheckedPrintWriter.java:295)
        at
org.eclipse.jetty.io.UncheckedPrintWriter.print(UncheckedPrintWriter.java:460)
        at
org.eclipse.jetty.io.UncheckedPrintWriter.println(UncheckedPrintWriter.java:642)
        at
org.directwebremoting.dwrp.PlainCallHandler.sendOutboundScriptPrefix(PlainCallHandler.java:49)
        at
org.directwebremoting.dwrp.BaseCallHandler.marshallOutbound(BaseCallHandler.java:317)
        at
org.directwebremoting.dwrp.BaseCallHandler.handle(BaseCallHandler.java:105)
        at
org.directwebremoting.servlet.UrlProcessor.handle(UrlProcessor.java:120)
        at
org.directwebremoting.servlet.DwrServlet.doPost(DwrServlet.java:141)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
        at
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:538)
        at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:478)
        at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
        at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:517)
        at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
        at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:937)
        at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:406)
        at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183)
        at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:871)
        at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
        at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:247)
        at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
        at org.eclipse.jetty.server.Server.handle(Server.java:346)
        at
org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:589)
        at
org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1065)
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:823)
        at
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:220)
        at
org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411)
        at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:535)
        at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40)
        at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:529)
        at java.lang.Thread.run(Unknown Source)
Caused by: org.eclipse.jetty.io.EofException
        at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:149)
        at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:96)
        at java.io.ByteArrayOutputStream.writeTo(Unknown Source)
        at org.eclipse.jetty.server.HttpWriter.write(HttpWriter.java:283)
        at org.eclipse.jetty.server.HttpWriter.write(HttpWriter.java:107)
        at
org.eclipse.jetty.io.UncheckedPrintWriter.write(UncheckedPrintWriter.java:271)
        ... 32 more
Nov 15, 2011 4:43:18 PM org.directwebremoting.servlet.ExceptionHandler
handle
WARNING: Error: org.eclipse.jetty.io.RuntimeIOException:
org.eclipse.jetty.io.EofException

Now I am using dwr-3.0.0-RC3-dev-363 and jetty-7.6.0. i am getting the same
problem of dwr request being sent twice, but the difference is I do not get
any exception at server side.
This behavior happens only at sometimes, but can be reproducible.

Can some one help me, what can cause this kind of behavior?

Thanks in advance

--
View this message in context: http://dwr.2114559.n2.nabble.com/DWR-request-sent-twice-tp7250229p7250229.html
Sent from the DWR - Users mailing list archive at Nabble.com.

buzzer | 7 Feb 17:35
Picon

[dwr-users] CachingHandler host and port in caching key

org.directwebremoting.servlet.CachingHandler uses request's contextPath,
servletPath, pathInfo combination as a cache key. This leads to cross-domain
related problems.

Imagine we have an application, which is hosted on the server with 2
host-ports: host1:port1, host2:port2. Once we accessed /engine.js/ as
/http://host1:port1/context/dwr/engine.js/ it will contain "host1:port1"
URLs forever. E.g. this /one http://host2:port2/context/dwr/engine.js/ will
contain line dwr.engine._pathToDwrServlet =
"http://host1:port1/context/dwr"; what is not correct

--
View this message in context: http://dwr.2114559.n2.nabble.com/CachingHandler-host-and-port-in-caching-key-tp7262906p7262906.html
Sent from the DWR - Users mailing list archive at Nabble.com.

buzzer | 7 Feb 17:42
Picon

[dwr-users] Re: CachingHandler host and port in caching key

Btw IMO it is better to pass the whole request (instead of its certain parts)
to methods like generateCachableContent(...), generateTemplate(...),
getSearchReplacePairs(...) etc, thus methods will be much more flexible and
easy to override.

--
View this message in context: http://dwr.2114559.n2.nabble.com/CachingHandler-host-and-port-in-caching-key-tp7262906p7262941.html
Sent from the DWR - Users mailing list archive at Nabble.com.

David Marginian | 7 Feb 18:00

[dwr-users] Re: CachingHandler host and port in caching key

Have you followed our cross-domain instructions?  Note steps 2 and 3 you are supposed to override paths to get it to work.
http://directwebremoting.org/dwr/documentation/browser/xdomain.html

"Btw IMO it is better to pass the whole request (instead of its certain parts)
to methods like generateCachableContent(...), generateTemplate(...),
getSearchReplacePairs(...) etc, thus methods will be much more flexible and
easy to override."

My guess is that the API was designed this way so that one could implement a CachingHandler that does not rely on having an HttpRequest. 


On Tue, Feb 7, 2012 at 9:42 AM, buzzer <abrir.fuego-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Btw IMO it is better to pass the whole request (instead of its certain parts)
to methods like generateCachableContent(...), generateTemplate(...),
getSearchReplacePairs(...) etc, thus methods will be much more flexible and
easy to override.

--
View this message in context: http://dwr.2114559.n2.nabble.com/CachingHandler-host-and-port-in-caching-key-tp7262906p7262941.html
Sent from the DWR - Users mailing list archive at Nabble.com.

buzzer | 7 Feb 18:55
Picon

[dwr-users] Re: CachingHandler host and port in caching key

Thanks, David, seems like points 2 and 3 should help in our situation.
However this approach a bit looks like a workaround. Looks like for better
design points 2 and 3 must be performed by DWR by default (until forbidden
explicitly), because this is not a rear case when application is accessed by
multiple URLs (each server has as minimum host name and IP address and often
tests are performed for "localhost" first). It is troublesome to apply point
2 before each engine.js ref and point 3 for every interface (what if
thousands of them!).
Our application has additional troubles, because we add (or not add) DWR
stuff into HTML depending on condition, so we need to keep in mind point 2
and 3 for each adding.
Any chance to change this? Not wanted to override CachingHandler descendants
and change DWR default configuration.

As for using request as an argument, all Handler descendants rely on
HttpServletRequest, because it is an arg of handle(...) method and should be
in classpath. Btw getCachingKey(...) method is already implemented in such a
manner.
Maybe it is even worthwhile to add both (request and response) as args for
further implementations, it would be not bad design.

--
View this message in context: http://dwr.2114559.n2.nabble.com/CachingHandler-host-and-port-in-caching-key-tp7262906p7263115.html
Sent from the DWR - Users mailing list archive at Nabble.com.

David Marginian | 7 Feb 19:05

[dwr-users] Re: CachingHandler host and port in caching key

Both step 2 and 3 can be skipped IF the url is known ahead of time.  Per the docs:
"If the remote URL is static/known ahead of time this step can be skipped in place of setting the overridePath parameter. "

Have you tried the overridePath parameter?

"As for using request as an argument, all Handler descendants rely on
HttpServletRequest, because it is an arg of handle(...) method and should be
in classpath. Btw getCachingKey(...) ."

Yes, you are correct.  Maybe we will change the API in the future.


On Tue, Feb 7, 2012 at 10:55 AM, buzzer <abrir.fuego-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Thanks, David, seems like points 2 and 3 should help in our situation.
However this approach a bit looks like a workaround. Looks like for better
design points 2 and 3 must be performed by DWR by default (until forbidden
explicitly), because this is not a rear case when application is accessed by
multiple URLs (each server has as minimum host name and IP address and often
tests are performed for "localhost" first). It is troublesome to apply point
2 before each engine.js ref and point 3 for every interface (what if
thousands of them!).
Our application has additional troubles, because we add (or not add) DWR
stuff into HTML depending on condition, so we need to keep in mind point 2
and 3 for each adding.
Any chance to change this? Not wanted to override CachingHandler descendants
and change DWR default configuration.


As for using request as an argument, all Handler descendants rely on
HttpServletRequest, because it is an arg of handle(...) method and should be
in classpath. Btw getCachingKey(...) method is already implemented in such a
manner.
Maybe it is even worthwhile to add both (request and response) as args for
further implementations, it would be not bad design.

--
View this message in context: http://dwr.2114559.n2.nabble.com/CachingHandler-host-and-port-in-caching-key-tp7262906p7263115.html
Sent from the DWR - Users mailing list archive at Nabble.com.

buzzer | 7 Feb 19:24
Picon

[dwr-users] Re: CachingHandler host and port in caching key


david@... wrote
> 
> Have you tried the overridePath parameter?
> 

This will not help here, because we don't know the host name beforehand and
/overridePath/ only allows to set one host name once and forever. Generally
our situation is kind of "we don't know the URL of our application". Because
of many reasons:
1) Different users access the app by different URLs (because of network
configuration nuances).
2) The IP and host name of the server is changed more often then application
is restarted.

--
View this message in context: http://dwr.2114559.n2.nabble.com/CachingHandler-host-and-port-in-caching-key-tp7262906p7263205.html
Sent from the DWR - Users mailing list archive at Nabble.com.


Gmane