I have created MarkLogic REST port on 6000 (say). The database contains few xml documents.
When I call the following URL on chrome it does not work
http://localhost:6000/v1/documents?uri=/transformed/1000004.xml
However it works on Internet explorer.
This is something strange because I have created MarkLogic REST port many times and it has worked on chrome.
Can anyone please help with what might be the reason??
N.B : Application uses 'application-level' authentication and default user is 'admin (admin)'
MarkLogic will be responding the same way regardless of the browser; I think the most likely problem is with Chrome's presentation of the results. Use the "View Source" option and you should see the XML.
Related
Let's say I have some website with the name website.eu. When I deploy it and try to get access to a page online like this website.eu/about I catch the error:
"404 The page you're looking for could not be found. The resource that you are attempting to access does not exist or you don't have the necessary permissions to view it"
When I click on the link that brings me a website.eu/about it works well, but trying to type that URL in the input field it fails.
Everything works fine locally.
The project is developed using Vue3.
The project is no GitLab.
If someone helps I would appreciate it.
Hard to tell without seeing the code, but my guess is your router setup uses the web history mode, which relies on the server to have certain settings applied.
I believe switching to hash mode (while adding # to the routes) will work.
Alternatively, you can update your server to support redirects to have the html mode work.
example server configurations
So, I have a Spring-MVC RESTful backend, that is cross-domain enabled. It is unit-tested, I can call my web-services and get back the correct JSON.
I have a SmartGWT 5.1p and GWT 2.7.0 front-end application that works great in SuperDev mode or Classic Dev Mode, either works great. When I do this, I am using the old Firefox 24 browser with the GWT plugin, and I can see my app work just great. My datasources are tied to RESTful web-services, and I can create, retrieve, update, and delete records via my DataSources.
I can compile the whole app via Maven, and get a WAR created just fine. I tried moving this WAR over to a tomcat server, and it deploys correctly. I can see the app running in tomcat with no errors in the logs.
Then when I go to the first page, the app comes up s normal with no errors. The first thing I do is add a username and password into a form, and then it is supposed to call a LoginDataSource which is tied into a LoginCOntroller, or login web-service.
What I can see from firebug is that when I make my call, rather than just calling:
http://mydomain:8080/admin/login/user/myusername/pwd/mypassword
I get:
http://mydomain:8080/admin/login/user/myusername/pwd/mypassword?0{and a whole lotta stuff after this) ... the query string I presume.
When I hit the Submit button, I get a SERVER TRANSPORT error, and that's it, I don't get any more information that that. There is nothing else to report from firebug except that the OPTIONS and GET add a whole lot of query string nonsense after the password.
I can look in the tomcat logs, and I don't see any errors in there at all. I don't even see the URL call to the web-service.
Any help on this would be much appreciated. I've been dealing with SmartGWT for years, and switched to back-end development for a while, and not I am trying to make my SmartGWT front-end work as well. But, I am a little rusty as to what is happening now.
Thanks!
The problem is not the querystring, it's the old base url I have in the datasource. There is a method in each datasource called: getServiceRoot
In getServiceRoot, I was using a hardcoded "localhost:8080", which in client code that doesn't work. That means whoever is running the app in their browser, "localhost" means their machine. So, I had to change the getServiceRoot to do the following:
protected String getServiceRoot()
{
String baseUrl = "http://" + Window.Location.getHostName();
return baseUrl + UrlConstants.SOME_URL_REST_ENDPOINT;
}
Since I have two WAR's on the same machine;
one WAR is a Spring MVC back-end RESTful web-services
the other WAR is the front-end, SmartGWT client application
This is a problem I run into ... I think just because both are on the same machine, that to the front-end, just call the code on the localhost, because it is there. But to the browser, that could be any other machine.
I suppose I could have just hard-coded the public IP address of the machine running tomcat, and then the client-side SmartGWT would then certainly find the RESTful web-services. Or, I could have used a Spring Env Profile to make that happen as well. But the code change I made should work, provided both WARS are on the same machine.
I just got to remember that client-side code in a browser is relevant to the machine the browser is running on.
So, this is fixed. If anyone needs any clarification, please let me know.
I have a c# console application which post .csv content to a web service. If I run my solution through VS, it runs perfectly fine but after deploying web service on IIS I keep getting Multiple Choice Status Code 300 error. Not sure how to resolve that. Any pointers would be appreciated.
Thanks
These are relatively simple but I cannot think of other possibilities based on your description.
One of my recent designs had a literal in the code that when I deployed it ended up using a different port which I had forgotten to change to a relative reference.
If not that then the other problem I had with it was because I used JSON to link to the web service. While it worked when viewing in VS when deployed my JSON reference was actually incorrect. specifically it had to do with code in my web.config file, which would be the app.config file for your console application. I had used the code
standardEndpoint helpEnabled="true" automaticFormatSelectionEnabled="false" crossDomainScriptAccessEnabled="true"
when I should have also added
defaultOutgoingResponseFormat="Json"
to make the code work
Before I begin, I'd like to appologise for any improper terminology. I am in a jack-of-all-trades position right now and LCMS/LMS systems are not my primary focus typically.
Goal:
Create content that is stored and edited in Kenexa (Formerly Outstart) LCMS and is accessed via AICC URL in the Moodle LMS. This is important to us because we'd like to have the content in a central repository (the LCMS), where changes can be made to the content and instantly applied to the LMS(s).
Problem:
Unable to connect to LCMS content using an AICC URL (generated by the LCMS) using Moodle LMS. When connecting, I receive this error:
AICC HACP Entry Point Error
AICCException : The callback to the LMS failed with http status code (404)
When creating the AICC URL, the LCMS will present an error if I supply an invalid or unreachable URL for my LMS. In this case, the LCMS can "see" the LMS, as far as I can tell.
Details:
The LCMS uses an editable XML file when publishing the AICC URL and content. That file looks like this:
<publish_configuration>
<destination>
<id>{instance_id}</id>
<label>{instance_label}</label>
<url>{protocol}://{destination_host}/{pens_context}</url>
<standard>pens</standard>
<transport_location>{protocol}://{source_host}/{repository_context}</transport_location>
<transport_userid>{transport_user}</transport_userid>
<transport_account>{transport_account}</transport_account>
<transport_password>{transport_password}</transport_password>
<system_userid>{system_user}</system_userid>
<system_password>{system_password}</system_password>
</destination>
<destination>
<id>02</id>
<label>Moodle_Test</label>
<url>http://LMS-URL/moodle</url>
<standard>pens</standard>
<transport_location>http://LCMS-URL/LCMS/evsfiles/exports</transport_location>
<transport_userid></transport_userid>
<transport_account>FIRST_USERID</transport_account>
<transport_password>FIRST_PASSWORD</transport_password>
<system_userid>SECOND_USERID</system_userid>
<system_password>SECOND_PASSWORD</system_password>
</destination>
</publish_configuration>
Fiddler shows that a request is sent to the LCMS when the AICC URL is launched and receives a "200 OK" header response.
We've been using the second "destination" option in the XML and it seems to generate the AICC URL correctly, from the LCMS's point of view. When launched, directly in the browser or from the LMS, the error from the beginning of this question pops up.
We have another type of LMS using these AICC URLs and it is working correctly, however we are trying to take this method and apply it to many different sites that are all using moodle.
System Information:
LMS:
Moodle: Version 2.3.2 (Build 201220910)
Apache2: 5.0.8
PHP: 5.3.16
MySQL: 5.5.21
Enable direct AICC url checked
Enable external AICC HACP checked
LCMS:
Kenexa LCMS: 8.2.0073
Tomcat Application Server: 6.0.32 (Bundled with LCMS)
MSSQL Server: 2008 R2
General
- Both applications are running on the same server.
- No internet connection to server.
- Local Address (192.168.1.10) doesn't work correctly in the publish.xml file
Questions:
Is it possible that PHP or Apache are blocking the AICC communication between the LCMS and the LMS?
Could this be a Moodle issue with AICC URLs?
I'm not sure if there are any other questions I should be asking in relation to this. I don't know enough about the inner workings of AICC/MOODLE/Kenexa LCMS to pinpoint the issue here. My usual solution would be to google until I find a similar issue and tailor their solution to fit my issue, but I am having a hard time finding anything like this.
If you need any more information, logs, etc, please let me know!
Thank you in advance!
UPDATE - 15/7/2013
After digging around the "fantastic" Moodle forums, I found a link to this bug report. Now, this didn't sound exactly like my problem, but I was running out of ideas so I gave it a try.
How to fix this issue:
Navigate to the SCORM Lesson Settings
Find "Display course structure in player"
Disable
Save and Display
I'm assuming that the JScript used to populate the "Table of Contents" in the content player is having issues with the AICC URL. As far as I can tell, the AICC URL does not provide any "course structure" so the Jscript fails to build the ToC and thus causes some deeper issues with the AICC content being displayed. (Most of this is assumption, would love for someone else to verify).
Quoting my update from the original question:
After digging around the "fantastic" Moodle forums, I found a link to this bug report. Now, this didn't sound exactly like my problem, but I was running out of ideas so I gave it a try.
How to fix this issue:
Navigate to the SCORM Lesson Settings
Find "Display course structure in player"
Disable
Save and Display
I'm assuming that the JScript used to populate the "Table of Contents" in the content player is having issues with the AICC URL. As far as I can tell, the AICC URL does not provide any "course structure" so the Jscript fails to build the ToC and thus causes some deeper issues with the AICC content being displayed. (Most of this is assumption, would love for someone else to verify).
I am hosting my pages on my doamain. I put the following info. When I go to view the app it shows 405 Method Not Allowed..Not sure what I am doing wrong.
*
The first page load a APP makes is a POST request.
Seems your server could be rejecting them.
Its worth checking the server side error log for further information.
Indeed, it will most probably be a setting on your server. I had the same problem, my server didn't allow POST method on .html pages, changed my canvas page source to .php and all works fine now.
If you can look at your apache logs, it will provide a more clear error that we can help you debug with. Though a 405 error typically signifies a problem with the server and usually stems for a POST request.
I have made the mistake 2 times of creating my site in html instead of using a scripting extension. For example, if you are running on a Windows server and coding in Visual Studio, it is tempting to just create .htm or .html files. However, most web servers will not allow a POST operation to these pages. Instead, create .aspx pages, which will still allow you to use the same exact static HTML and JavaScript. This solved my problem in both cases.