I'm using ElFinder.NET connector in my MVC applications. In one application everything works fine, but the other application can't initialize Elfinder.
The code used to initialize Elfinder is the same in both applications. The problem is probably in Connector.Process(this.HttpContext.Request) call.
In the application, where ElFinder is working, Connector.Process returns JSON result with correct data, the other application returns a wierd result.
I can see in the browser, that the request was processed, but the response body contains string System.Web.Mvc.JsonDataContractResult instead of JSON data. If I step through the code in Visual Studio, I see that Connector.Process return a JsonDataContractResult but it's empty.
Well then :)
Possible situation is; outdated Json.Net(Newtonsotf.Json) package version. If you have an older version of this library please simply replace them with the ones in elfinder's package as i say on my comment..
Related
We are currently upgrading PHP form 7.1 to PHP 8.2 for a legacy application which uses Apache, FriendsOfSymfony 1.5.15, ExtJs 3.4 and ExtDirect.
The following problem occurs: Sending a request to the Symfony backend creates the result as expected. The ExtDirect plugin, dsExtDirectPlugin, handles the request and response until a certain point in the dsExtDirectRouter.class.php where the code echos the response from the Symfony endpoint:
echo json_encode(self::$response);
From this point on Symfony shutdowns down logging,... and I expect that the response echod is used in JavaScript from that point on, but in the Firefox development tools, I see "no data available" in the network tab. So the output doesn't seem to come to the frontend / is suppressed from being echod?
Does anyone have a clue what can cause this? Do I need an additional php or apache config?
Thanks and kind regards,
Dirk
I found the solution for my prolbem: fastcgi_finish_request seems to be executed too early. Probably there's still some kind of misconfiguration on the Apache / PHP. If I directly add the fastcgi_finish_request call after the result "echo" and comment out the method call in the sfWebResponse (cached) class, it works. Of course not the final solution to comment something out in a commented class, but at least knowing the problem is a first step to the final solution.
I'm having a web reference which is being used by both a Xamarin IOS application, Xamaring Android application, and a Windows Store application.
And this all worked very well, until I updated Xamarin.
Now, there is a field that But it works fine for the Android and Windows applications.
I have tried to update the web reference multiple times, with no luck. I have also tried to debug the web service locally, to see if it returns the same , which it does.
When I receive it in my Windows Store app., it looks like this:
And in my IOS app., it looks like this:
It is always the StructureId that is never set, for some reason. And it was not like that before I updated Xamarin.
Anyone who knows what I am doing wrong, or have stumbled onto the same kind of problem ?
That looks like the linker removed unused members. Defaults have not changed (it's not related to your update) but you should check that your application is being built with Link SDK (and not Link all).
If you want a smaller executable and set Link all to achieve this then you'll need to add [Preserve] attributes on the structure you're serializing (e.g. used in web services).
I was able to make it work. I am not sure if it cached anything, or what, but it helped to add some "noise" on the webservice call.
I just added DateTime.Now.Ticks to my webservice URL in Reference.cs, so it would always be a new URL call:
this.Url = "http://somewebsitename.com/ReportService/ReportService.asmx?v=" + DateTime.Now.Ticks;
I've just created a new project and installed the file and file-transfer api's via CLI. I have already created a working app previously so I know how to use phonegap and have been doing so for a few years now.
Here is the code:
window.resolveLocalFileSystemURL("file:///localhost/var/mobile/Applications/96B4705C-C70D-4340-9A42-HJ1F28355D43/tmp/cdv_photo_015.jpg", function(fileEntry){
console.log(fileEntry.name);
}, function(error){
console.log('about to resolve this files errors');
console.log(error.code);
});
Nothing ever gets outputted in the console debugging window ...and yes I have debug installed cause I have console.log() in other parts of my code that show up.
It seems like there is an issue when passing URL data from navigator.camera.getPicture() to the file API when using window.resolveLocalFileSystemURL()...any ideas anyone. I'm up to date on phonegap api and everything and I have this issue for the past few days now...I can't seem to solve it.
***EDIT***
Seems like when you use Camera.DestinationType.FILE_URI as a parameter for navigator.camera.getPicture(). When you choose a picture and the success call back for navigator.camera.getPicture() is triggered, trying to window.resolveLocalFileSystemURL from the URL that getPicture returns just fails. But if you set Camera.DestinationType.NATIVE_URI it at least returns something but it's in a format that can't be used with the file-transfer api exp: assets-library://asset/asset.JPG?id=220BCEAE-F1EA-4A6A-83B2-AB8833A90BF2&ext=JPG
Seems like this was a bug in the file api v1.0.0
https://issues.apache.org/jira/browse/CB-6116
Temp solution is there as well.
Seems like "/local/" was causing the issue. Remove it from incoming uri's if it exist and the resolve should work.
Please see my post on the Grails user mailing list. Essentially, I get the error "Cannot forward after response has been committed" with Grails 2.x after every few requests. This happens for all types of URLs, controllers, GSPs, CSS files, JS files and even image files. I have tried Grails 2.0.0 and Grails 2.0.1 with Tomcat 6.0.35 and Tomcat 7.0.25 on Windows XP 32-bit, Windows 7 32-bit and Centos 64-bit. The error comes up on all these combinations.
As I have mentioned in my post, there are no response.redirect or response.forward statements in our code. This is causing severe problem on our production application so need help in determining what else can be looked at to get to the bottom of the problem.
This has been solved. In one of the controllers in the application, response output stream was being directly written to but not closed explicitly after the operation was over. It seems Tomcat and Jetty recycle response objects. When a response object that did not have their output stream closed earlier was recycled for a future request and redirect was performed on it, the redirect would fail.
The code has been changed and the error has disappeared now. The lesson learned is that any time such an error occurs, scan the entire code base for direct access to response output stream and close output stream responsibly before existing controller methods.
You should create a new grails application and move the controllers, domains and etc yourself rather than grails update.
When you do that also make sure you look into the configuration files of grails.
Also take a look at what plugins you have.
Also, when moving the files, try out the application once in a while when it is possible, and perhaps you can detect when the error arises. Start out by trying it in your most basic controller and see if the error is there then as well.
Good luck.
We've recently setup out own webservice using SOAP and it all works like a charm.
Because the service is only used from within our own applications, I usually don't allow for a WSDL to be generated.
Today i started some tests with SoapUI and needed a WSDL of our own service. So I enabled the Default action of the TWSDLHTMLPublish component and tried to get the WSDL exported. All I got was an access violaton in WebServExp.GenerateXMLSchema, line 1636:
if (ParentInfo = nil) and ((GetTypeData(ATypeInfo).ParentInfo)^ <> nil) then
Debugging this, reveiled that GetTypeData(ATypeInfo).ParentInforeturned a nil, so of course using ^ on nil raises an access violation.
After removing the carret i had no problems generating the WSDL.
So did I find myself a bug here or am I missing something?
BTW: We have created our own SOAP.bpl, containing all original Delphi soap sources, to correct it for a known problem with exception derived from TRemotableException
So did I find myself a bug here or am I missing something?
Yes, that's a bug. And Subversion reveals it's been like that for many years - for as long as we've been on Subversion:(. [I am not setup to access the previous Starteam repository anymore].
I'm making to a note to remedy and check in unit tests for this. Please feel free to file a QC if time allows. And I'd like to hear more about the issue with TRemotableException-derived types.
Cheers,
Bruneau