I have a few Google App Engine standard Java environment applications that are backends for mobile apps, there are both Android and iOS clients.
Some time ago I received an email that the Cloud Endpoints v1 will be no longer supported and that I need to migrate to the new version v2.
What happens to the already existing (and using endpoints v1) mobile clients when I upgrade the version of the server?
My Android clients use maven-generated libs and the integration with iOS is based on discovery docs generated by another maven command.
I'm afraid that after the upgrade the clients will not be able to communicate with my backend anymore (as long as they do not update their libs / docs). As we cannot make the app-users upgrade their apps, I hope that the server changes will not affect all the clients that are already running on production.
No. It will not affect anything. The old version would not be supported after 2, August 2018. The new version has few benefits as given in the documentation.
Reduced request latency
Better integration with App Engine features (such as custom domains)
Official support for Guice configurations
Optionally, new API management features
Please follow the instructions given here. I have shifted to the new version just a few days ago and everything is working as usual.
Related
I want to use this java client library for Kubernetes from app engine. But I ran into issues because this client library uses okhttp client which doesn't work in app engine as per this link.
The error described in the previous SO link is the exact error I am getting on app engine.
As per this link, okhttp exposes the method which can be over-ridden such that this issue isn't seen. There is actually a library for this here. But the issue is that the OkHttpClient has been moved from package com.squareup.okhttp to okhttp3 from version 3.x onwards in which the changes that I require are present. This old version of okhttp is used in the Kubernetes client library and shows error if I try to set the new okhttp.
Is there any way to solve this issue? Or are there any other client libraries which can be used from app engine. I know of client from fabric8 but it has support only till kubernetes version 1.7.10 as of now. I still haven't tried it on app engine though.
Edit:
Even the fabric8 client has the same issue in app engine. It is trying to get the ProxySelector which is not a whitelisted class in appengine.
Alternatively, you could try the Java 8 runtime where you can use all the standard Java library, unlike the Java 7 runtime which allows only select whitelisted JRE classes. After all, the Java 7 runtime is now deprecated: https://cloud.google.com/appengine/docs/standard/java/runtime
However, do note that there are some differences, so you may want to take a look at the migration guide: https://cloud.google.com/appengine/docs/standard/java/migrating-to-java8
As google mentioned in "Discontinuing support for JSON-RPC and Global HTTP Batch Endpoints", Google API Client Libraries have been regenerated to no longer make requests to the global HTTP batch endpoint.
I am currently using the Google API Client Libraries for Java(v1.20.0) to create/modify/remove users and to grant/revoke roles to GSuite via Google Admin SDK and Batch.
I searched for the latest version on Github, but there was no new release after publishment of this article.
I'd like to know whether the latest version on Github (v1.23.0) includes the update in endpoint? (which means I can just simply update to v1.23.0 and use it instead of the current version I am using).
Regards,
In fact, yes, the update to API specific URLs was in v1.23.0. Make sure to update your google-api-services-* library versions too.
I'm a beginner in context of google-cloud-endpoints and the associated product "google-cloud-app-engine".
I've created a simple google app angine project/application and created an API-Key by using the google cloud platform's console.
To my app-engine's endpoints API definition I've added the annotation
"apiKeyRequired = AnnotationBoolean.TRUE" as stated in
Add API restriction by adding an API key to your app engine application
and my client application which uses the generated endpoints client API was also updated accordingly to send the generated API key for all API requests.
As I would like to test the "API-Key" mechanism locally on my development machine (using a local app-engine environment) before deploying the backend to the cloud, I would like to know, whether it is possible to test the "API-Key"-restrictions locally. I mean, somehow the locally executed app-engine backend app has to be aware of the created API key. Maybe there is a property which I have to provide to my app-engine backend application's POM.xml file...I don't know, whether the google app-engine SDK supports API keys for local testing in context of the "endpoints framework v2" actually. The newley introduced API Management Platform (API-Gateway) can maybe not be "simulated" locally...?!
Thank you so far for your effort!
API key restrictions should work locally. You just need to include GoogleAppEngineControlFilter in your web.xml.
There are several examples of configuring the service bus environment to use http/https with C#, using the call:
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Http;
My question is - can and how do I do this via a java client?
The newer versions of the SDK (1.0 and later) do not support HTTP connectivity (AMQP only), and the older ones do not support AMQP (HTTP only). As a result there's no "need" for connectivity mode settings.
The Java SDK is AMQP only.
If http is what you want, try Azure SDK for Java older version, which is http only. It can be found at https://github.com/yvgopal/azure-sdk-for-java/blob/0.9/services/azure-servicebus/pom.xml. Be careful with the version of the package as the new AMQP only SDK also has the same package name. You should be good with any version starting with 0.9, but before 1.0. Also note that the SDKs are completely different. Applications written with one SDk don't work with the other SDK.
https://github.com/Azure/azure-service-bus-java/issues/171
we are trying to implement linkedin into our application and we want to use Rest API so we can share network updates via back-end using OAuth token to our own linkedin account
JavaScript API wont work for use because its token expires every 30 minutes and we have to login in every time (if more than 30 mins) to share network update. so we want to use REST API and OAUTH token to share network updates with java
we have considered Scribe and Spring Social (though spring social's linkedin module is still in release candidate as of now) but to use those library we need higher version of java and we are using java 1.2 right now with the application
is there a way we can still use the REST API and make OAuth calls to share network update or is there a Java library for OAuth that still supports java 1.2
Any help or direction would be appreciated
Thanks
There's no OAuth lib that works with the LinkedIn Api for java 1.2, in fact I'd argue that the only library that works well with all LinkedIn endpoints (because of some corner case encoding issues) is scribe.
Most of scribe code is 1.2 compatible. The only issues being some generics (Map<T,U>) and #Override annotations, which shouldn't be that hard to change.
If you're interested in digging the source and copy-pasting the bits you need (scribe is MIT licensed so you can do pretty much whatever you want with it), the core of the signature process is on this class.
Good luck.