Closed JCASTROE closed 4 years ago
Thanks for your report! This is an easy fix so you do not need to provide a pull request.
When do you plan to release the fix?
Any news about this? Is there something we can do to help?
Sorry about the delay. We got stuck on some process issues we wanted to sort out to get more fixes into the next maintenance release. I'm hoping to get this sorted in February/March and be able to publish a release after that.
First of all. Thank you for working on this project and maintaining it. I'll confirm again, but for this bug I was trying to get it working with Spring Boot 2.2.2 and I am getting what appears to be the same issue as I would expect it not to be fixed. I did then pull the master branch for this project and tried building using that jar with no success. Also tried just manually patching from the stable release the patches linked here. I'll try to verify again as I was having some odd things go on with ant, mostly just had to disable some tests. Let me know if there is some other branch or something I should test with.
Ok I have played with this a bit I don't know what I am doing with it much, but Building from master and testing I still get the same error. I changed the SpringContainer addParameter class to use the LocalUtil.classForName instead of the Spring ClassUtils.forName and now get some different errors. But it does seem to be working.
Errors:
org.directwebremoting.log.startup : Can't cast: org.directwebremoting.servlet.PublicPeriodCacheableResponse@6fefce9e to org.directwebremoting.servlet.CachingHandler org.directwebremoting.servlet.PublicPeriodCacheableResponse@c65a5ef to org.directwebremoting.servlet.AboutHandler org.directwebremoting.servlet.PublicRevalidatingResponse@5cc69cfe to org.directwebremoting.servlet.IndexHandler org.directwebremoting.servlet.PublicRevalidatingResponse@55f3c410 to org.directwebremoting.servlet.TestHandler org.directwebremoting.servlet.UncacheableResponse@76a82f33 to org.directwebremoting.servlet.NotFoundHandler org.directwebremoting.servlet.UncacheableResponse@74bdc168 to org.directwebremoting.jsonp.JsonpCallHandler org.directwebremoting.servlet.UncacheableUntransformableResponse@611f8234 to org.directwebremoting.dwrp.BaseDwrpHandler org.directwebremoting.servlet.UncacheableResponse@62923ee6 to org.directwebremoting.jsonrpc.JsonRpcCallHandler org.directwebremoting.servlet.UncacheableUntransformableResponse@f19c9d2 to org.directwebremoting.servlet.ExceptionHandler org.directwebremoting.servlet.UncacheableUntransformableResponse@4fd4cae3 to org.directwebremoting.servlet.DownloadHandler
Also for some reason I had to disable tests in build.xml as they would all fail saying that No tests eg: [junit] No tests found in org.directwebremoting.impl.YahooJSCompressorTest
Hey folks, just want to let you know that I am working on this issue now. Sorry about the extended delay.
The basic problem here is quite simple (classloader behaviour for illegal classnames) but DWR's logic here is a bit quirky and there are a number of codepaths in addition to Spring that are affected, so care needs to be taken. I hope to propose a solution this week.
Please try out these updates I just committed and tell me if they make things work in your problematic scenarios.
If I don't hear anything for a few days I will close the issue.
I ran a quick check, at least for Airsonic everything seems to be working for both Spring Boot 1.5 and 2.2. Thank you so much for looking into this!
Looks like it works for me as well! Thanks a lot.
Although I still do have the problems with ANT and tests. First still gets the UTF8 test not able to compile as well if I don't comment out the test I get the error mentioned above. I don't know enough about ANT setup so I imagine it is a local issue for me if it works for you.
Ok good to hear, so I will close this issue now.
Regarding your test running issues I have committed some small updates to exclude tests with demanding environment requirements to make the default run easy to get going. It runs cleanly from inside Eclipse. Moving on, please keep your questions outside the issue system and use the forum at https://discourse.dojo.io/c/dwr-users instead.
Thanks all for your contributions!
@mikewse Is there any way we can get a maven artifact released with this bug fix?
@mikewse Or any workaround you can think of in the meantime?
We have ongoing work with replacing our CI/build setup so we can't release new artifacts until that's done. Might be a few weeks if things goes well, longer if not. You can always build dwr.jar locally yourself and use in the meantime. Please keep any further questions outside the issue tracker and use the forum at https://discourse.dojo.io/c/dwr-users instead.
download the source code and compile the master branch (dwr-3.0.3-SNAPSHOT) to solve the problem :clap: :point_down: dwr-3.0.3-SNAPSHOT.zip
@mikewse , just wanted to check if the artifact for this change will be released . I faced the same issue and fixed it using the jar shared above but I have to package it locally .
@kashrish have you tried Maven OSS? I think the latest snapshot artifact is there - http://directwebremoting.org/dwr/downloads/index.html.
When porting an Spring MVC/DWR application to Spring Boot 1.5.6/Spring MVC 4/DWR 3.0.2-release the exception bellow happens, this issue dosen´t happen when running inside an IDE. I found out that that SpringConteiner behavior depends on classloader behavior the methord void tries to addParameter(String askFor, Object valueParam) with askFor = response:org.directwebremoting.servlet.CachingHandler but the classloader is the org.springframework.boot.loader.LaunchedURLClassLoader that, instead of throwing a ClassNotFoundExeption, throws an java.lang.IllegalArgumentException - because it interpreters as an illegal url that begins with response. I will pull a request correcting this.