I remember that I used to be able to access the older http://localhost:8761/eureka/v2/apps and could see the raw JSON for the apps form the discovery server (spring cloud).
I just tried it recently and no longer see it. Has it been moved? And if so, where?
I should have read further. It was changed to http:/localhost:8761/eureka/apps.
Still works but change in URL
Related
When one creates an ASP.NET Core Web API in Visual Studio 2022, and tests it locally, one gets a convenient Swagger page built upon an OpenAPI definition, to test all HTTP endpoints.
However, when deployed and trying to access {path-to-api}/swagger, it returns a 404 Not Found error, even while on localhost, when both the API and the database is sitting on my own machine. Even if the database is in the Azure cloud, for that matter, it also works, if I put the Azure SQL Database connection string into appsettings.json.
So is there a way to achieve this, preferably without too much hassle? Or am I wrong in wanting this, do developers mostly test their APIs locally? Because I want the Swagger API online only for testing.
The problem is getting and using the swagger functionality into the cloud. Is it possible and good practice?
If you look at the startup, you will notice that the swagger is only loaded during a development session via an if check. Commenting that out, or expanding it based on evironment, will allow a published version to generate the page on the target host.
if (app.Environment.IsDevelopment())
{
app.UseSwagger();
app.UseSwaggerUI();
}
I generally do that for first publishes or to Dev/Test environments to see it running. Once it is not needed, I un-comment it back in.
Also it may be actually viable (turned on) in Dev or UAT server because one is also publishing the open api it to APIM (Azure api manager), which takes the api and generates its own development environment; away from an initial publish.
Also once published, it is not the default page, one still has to path to it such as .../swagger/index.html.
I'm aborting this mission to deploy the Swagger interface to Azure along with my API. It's bad security practice to make the HTTP request methods so visually available to all. So the answer to my question do developers mostly test their APIs locally, is apparently yes.
I wondered if I should remove the question, but I would like to make it still stand, in case anyone else is contemplating about doing the same thing - exposing an API online with the Swagger UI.
I'm trying to use spanner emulator and I followed the instructions reported here:
https://cloud.google.com/spanner/docs/emulator
to set it up.
I can use gcloud shell commands to create instance, database, tables, etc. and all works correctly.
But I am not able to use the Rest API directly to access the emulator, even though the google documentation reports it is possible not only to use google client libs to access the emulator, but also the rest api.
The first problem is that it is not clear if I have to use either the base URL
https://spanner.googleapis.com/
or
http://localhost:9020/
When I try with
http://localhost:9020/v1/parent=projects/local-project/instanceConfigs
I always returns and "Not found" message, which means the the Rest API ws are responding, but through gcloud commands I can manage such instance and project!
What am I wrong with?!
According to the official documentation :
Using the Cloud Spanner
Emulator
"The Cloud SDK provides a local, in-memory emulator, which you can
use to develop and test your applications for free without creating a
GCP Project or a billing account."
Therefore you should use the localhost (localhost:9020 for REST requests).
You should use http://localhost:9020 to access the emulator if you want to manually access the REST API, so you were on the right track there.
The URL should however be http://localhost:9020/v1/projects/test-project/instanceConfigs to list all instance configurations on the emulator. Use http://localhost:9020/v1/projects/test-project/instances to list all instances.
I've been installing our very own ArcGIS Enterprise instance on AWS.
The instance I chose is ArcGIS Enterprise on Ubuntu.
It is important to mention that this installation was conducted without using Cloudbuilder. I know it is a tool that automates the process but I was introduced to it only after I have already started to attack my current instance problems head-on. So, please don't advise me to restart the whole process from scratch using it.
The current status of my instance is that my ArcGIS Server is working. I can access it, upload services and we have already started using it in out Staging environment.
I have authorized all of the software on the server and verified it is licensed. The Portal for ArcGIS is my main problem.
Whenever I try to access it externally(from my office computer) it seems to redirect to the internal IP for some reason, and then times out on that request.
for example typing(from my browser):
https://[dns address]:7443/arcgis/home
redirects to:
https://[internal IP]:7443/arcgis/home
and this times out. (...took too long to respond error)
The funny thing is I can access the portaladmin area.
it's only the portal itself which doesn't work.
Also, another curious thing is that if I type without using the ports, I can access a window but exceptions are thrown in the browser.
For example:
https://[dns address]/arcgis
This will lead to a window where the ArcGIS world icon can be seen but nothing else loads and there are exceptions for "resource not found" 404 on some of the components of this page.
Any ideas? What further information should I include to answer this question?
I've looked everywhere but Esri's documentation is not very forthcoming with examples and information to understand what it is I did wrong.
Also, I don't think this is a ArcGIS software issue. It looks like this might be a proxy issue. Anyone else experienced something like this?
Thanks!
I found the solution.
It was a combination of two problems:
Tomcat that was running the web adaptor service was crashing because of an entirely different and unrelated issue.
The Portal was missing a web adaptor configuration and therefore did not have the WebContext property set with the web adaptor URL.
After fixing both of these problems, I was able to access the portal correctly.
So I've read the documentation for enabling Plugins, but there doesn't seem to be a way to add new plugins other than for the ones already packaged.
I've tried grabbing the google cloud storage connector jar and sticking it in the 3rd party folder and starting Drill, but it doesn't seem to pick it up. I get an error that it doesn't recognise the protocol (gs://, as opposed to s3:// which works obviously).
Has any managed to do this? There seems to be zero information on getting this working, although Drill does claim to be able to work with google cloud services.
I'm working with Google App Engine in Eclipse w/ JSP pages in Windows 7.
I already have an app deployed and working, but I am unable to make changes to it for some reason.
If I make changes and debug locally, my localhost page is showing the changes that I implement.
While I am not getting any errors in the deployment, the same changes that work on my local debug are no longer showing up, so I can't update my app.
I thought updating the version number might help, but I had no luck with this.
Any ideas? Thanks.
Are you deploying the same version (as specified in appengine-web.xml) as the default version that is running on your app? If not, you'll have to access your new deployment at http://newversion.appname.appspot.com, or change your default version in app engine to your newly deployed version.
I have had the same problems too, especially when the changes concerned the static pages. Some little things to check:
If you have set an expiration date in your app.yaml, your browser cache could be holding the file.
If it’s specific to the online contents, it could be an intermediary cache (such as a squid server) serving the outdated contents, in which case you’d have to flush the cache to get the new version.
You could start by checking the log on the GAE console to see if the request is received by the server, that would help you debug.
Another trick, if you’re being served an outdated version of http://yourapp.appspot.com/index, try and pass a dummy argument to force the browser to update the version, for instance : http://yourapp.appspot.com/index?p=1