Is there any problems using Google Cloud Endpoints with custom domain?
I was using it for some weeks then, after a deploy it stopped to work. I look here and I found this question that says it is not allowed yet.
But it was working for me on http://www.customdomain.com/_ah/api/app-id/v1...
If you're using App Engine's built-in support for custom domains as outlined here, it's not expected to work. You can follow this feature request to keep up-to-date on the feature's progress.
Now,Google CloudEndpoints 2.0 support it
Migrating to version 2.0:
Update your dependency to use the new artifact. In Maven, this looks
something like below:
com.google.endpoints endpoints-framework 2.0.0-beta.8
Remove the legacy dependency, which is the appengine-endpoints artifact.
Update the API entry point in your project web.xml file:
Rename all occurrences of SystemServiceServlet to EndpointsServlet.
Replace all occurences of the path /_ah/spi/* to the new required path /_ah/api/*
See:
https://cloud.google.com/appengine/docs/java/endpoints/migrating
https://code.google.com/p/googleappengine/issues/detail?id=9384
Related
I've recently been migrating an App Engine (Go) app from Go 1.9 to 1.11. I've followed the steps in the
Migrating your App Engine app from Go 1.9 to Go 1.11 document, excluding the optional ones. I plan on doing the optional tasks later once I get this working.
I get the app to build and I can deploy it just fine. Most of everything works fine, with the exception of one API that is used to look up some info on a Google Play IAP. When I do that, I get the following error:
Error 403: Insufficient Permission: Request had insufficient authentication scopes., insufficientPermissions
I've checked, and the scope that I'm using is https://www.googleapis.com/auth/androidpublisher, which is still the scope listed in the Google Play Developer API documentation.
I'm using the App Engine default service account for the client by calling DefaultClient from the golang.org/x/oauth2/google library, which returns a client without an error
When I test the same code with Go 1.9, there are no authentication issues at all, and the API works. I'm guessing that these is something in the authentication setup which has changed but I can't find any documentation on it, nor on what I should do differently.
I have to imagine that a lot of people have had to do this migration, and I can't find any posts with this problem, so I'm lost as to why I'm getting it.
I think the issue is in the differences of runtime in Go 1.9 and 1.11. It doesn't seem to allow you to use Application Default Credentials anymore, you have to set them via a JSON file in 1.11. I found someone who had a very similar issue to you and they used a workaround by uploading a key and using that to get a Client.
Have a look here
Let me know.
I have an AppEngine project on https://myproject.appspot.com and I would like to be able to supply different versions of myproject if I, let's say, want to break backwards compatibility. The convenient way would be to have something like this:
https://myproject.appspot.com/v2 --> version 2 of my myproject
https://myproject.appspot.com/v3 --> version 3 of my myproject
I know I can deploy custom versions by doing: gcloud app deploy --version=v3. However, how do I fix this routing? Apparently, the different versions get their respective URL:s as desribed here: https://cloud.google.com/appengine/docs/standard/go/how-requests-are-routed. The pattern is https://[VERSION_ID]-dot-[MY_PROJECT_ID].appspot.com. This means that I would have https://v2-dot-myproject.appspot.com and https://v3-dot-myproject.appspot.com.
So, how do I do the routing? AFAIK I can't add this to dispatch.yaml. There I can only route to services and not versions or exact URLs.
The https://[VERSION_ID]-dot-[MY_PROJECT_ID].appspot.com format is the preferred way to manage versions in GAE. This gives you get the ability to split traffic between versions, which is very powerful for canary testing or a/b split testing.
If you were really interested to have https://myproject.appspot.com/[version numbers] then you could just roll out one version of your app with https://myproject.appspot.com/v2 and https://myproject.appspot.com/v3 routes all in the same version, but then you won't be able to split traffic via GAE routing.
You don't have to do anything specifically to obtain this routing, GAE does it for you automatically.
Just deploy the way you mentioned and checkout the respective URLs.
Google has described it here: how-requests-are-routed
Page says request can be routed to specific url by adding version number to url like below
https://[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com
If I have a project by named http://mycuteproject.appspot.com, then after reading above page I will think that a specific version can be accessed by http://20190705t200049.mycuteproject.appspot.com. But it is not like that, the url should be https://20190705t200049-dot-mycuteproject.appspot.com
When I do some changes in OpenAPI spec, which don't involve any changes in the code, do I need to redeploy the code along with the new specification?
When I deploy OpenAPI spec with gcloud service-management deploy command I get back in it's output new service configuration version, which I should set to the ENDPOINTS_SERVICE_VERSION parameter in the app.yaml file.
I'm not sure but it looks like I have to redeploy the app every time I deploy a new version of my OpenAPI spec, even when the application code doesn't change I still need to point it to the right service configuration version with the new ENDPOINTS_SERVICE_VERSION value, is that right?
If so, then it's different from what is described in the How API Deployment Works document for AE flex environment under the "Redeployment" section, where it says the following:
You can use the gcloud service-management deploy command to update
just the API specification without redeploying your backend API server
code or the Extensible Service Proxy. This is useful if you are
changing a configuration-only detail.
When you change the API specification, the Service Control API backing
your running service instances will pick up the change because as it
depends on the same service configuration.
Maybe someone could help to clarify how exactly it works in case of AE standard environment?
Are you using the Endpoints Frameworks? If so, then you will have to deploy the app when you make a new service config version, because, as you mentioned, the app.yaml specifies which service config to use.
using
gdata-contacts-3.0.jar,
google-api-services-drive-v2-rev43-1.12.0-beta.jar,
guava-13.0.1.jar
Google Drive works but not Google Contacts. (i tried all kinds of solutions but never got both working together on Google App Engine where as it works in local devmode.)
calling: ContactsService gservice = new ContactsService("...");
Caused by: java.lang.NoSuchMethodError:
com.google.common.collect.ImmutableSet.copyOf([Ljava/lang/Object;)Lcom/google/common/collect/ImmutableSet;
at
com.google.gdata.wireformats.AltFormat$Builder.setAcceptableTypes(AltFormat.java:399)
at
com.google.gdata.wireformats.AltFormat$Builder.setAcceptableXmlTypes(AltFormat.java:387)
at com.google.gdata.wireformats.AltFormat.(AltFormat.java:49)
at com.google.gdata.client.Service.(Service.java:558)
I had the same issue in my project, but it was solved when I used gdata 1.47.1. It can be found at http://code.google.com/p/gdata-java-client/downloads/detail?name=gdata-samples.java-1.47.1.zip
As I am using Maven, I uploaded it to my Nexus. Added dependency in pom.xml and it was started working.
One more thing to notice, I am using guava 13.0. If it helps you.
OK now it works. Nobody was able to see that i used to
Add Google APIs from the Eclipse Plugin.
This does not only just add new jars that do not work in combination but also leaves all those old ones in a subfolder in my project ".google_apis...". Somehow those made it to Google App Engine and the odyssey started.
After removing those ... everything works fine. So again and, as everywhere mentioned, i was using a mixed guava version bulk which human nature does not expect to being activated.
In my Google App Engine project, I'm currently using Twig for accessing the Datastore (but I suspect my question would be relevant for other 3rd party libs like SimpleDS, Objectify, etc.).
I was thinking that I should be able to delete some or all of the following JARs from my WEB-INF/lib folder:
datanucleus-appengine-[...].jar
datanucleus-core-[...].jar
datanucleus-jpa-[...].jar
geronimo-jpa_[...].jar
geronimo-jta_[...].jar
jdo2-api-[...].jar
But when I do, I get errors from Eclipse complaining that "The App Engine SDK JAR is missing in the WEB-INF/lib directory".
Is it really necessary to retain all these (unused) JARs?
If you're using the Google Plugin for Eclipse you can delete these JARs and then open the Properties for your Google Web Application project and open the Google > App Engine and then uncheck the Use datanucleus JDO/JPA to access the datastore. In fact, unchecking this box actually deletes these JARs for you.
I don't think you can delete them from the project (as you have said, eclipse starts to complain), but I've heard you don't have to upload them to your app, as long as you upload from the command line. This has the advantage that at startup your app won't have to load them up.
There are some details of uploading to app engine via the command line here and confirmation that you can do this here
If you manage to do this I would appreciate it it if you post links to the instructions you followed or post what you needed to do, as I have this on my todo list as well, but only got as far as seeing if it was possible. Thanks!