We are trying to automatically migrate traffic to the latest built version of our production branch of our app in google app engine. I can't find a good resource after about an hour of investigation on how to do this. Does anyone know if this is possible and where I can find resources on how to do this?
If you change the app/module version in your web.xml file at every build then you need to either assign the new version as the default version or migrate the traffic to the new version. AFAIK both of these actions can only be done manually, from the Developer Console's Versions Page.
But if you don't change the app/module version in your web.xml file then the updated code should automatically receive the same traffic as the previous code simply by deployment. At least in the standard GAE environment.
For Python applications it's possible to use appcfg.py set_default_version <app-directory> to set the default version to the one specified in app,yaml.
I'm assuming that appcfg.sh set_default_version <app-directory>, described in the documentation, does the same thing for Java applications.
Related
I'm looking for any kind of API or method of finding what the newest version of Windows is for a specified version. Is there any method to get this information?
As far as I know there is not a dedicated API supplying latest builds per Windows versions. There are several resources on the web supplying this information, you could compile these into a data set and create an API for your own use.
For example: https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions
Java 8 and prior versions have Java Web Start, which auto-updates the application when we change it. Oracle has recommended that users migrate to jlink, as that is the new Oracle technology. So far, this sounds good. This comes with a host of benefits:
Native code on Windows, Mac and Linux
Modularization of the code (although Proguard does this as well)
The use of new, supported technology.
The problem: I can't find the canonical Java solution to auto-update with jlink.
One would think that Java Web Start could continue to be used, especially if one casually reads this document. Notice the fact that Java Web Start continues to be prominently listed. But there's a fly in the ointment: Oracle is deprecating Java Web Start. It's slated for removal in JDK 11. So, what's the official path forward. Failing that, is there a standard way that people proceed?
For the purposes of this question the following are out of scope:
Paying huge amounts of money yearly to someone with an feature-packed enterprise solution. The application to be distributed is already packaged into a single jar that is smaller than 50MB.
Forcing users to run an InstallShield style app to reinstall the new version, and then manually uninstall the old version every time an update is pushed. That's sooo 1990's.
Porting the entire app to be a webapp, rewriting the UI and client side logic to fit in a browser and dealing with all the incompatibilities that entails. The authors of the application worked on GWT and know exactly what web browsers are capable of. Unfortunately, they also know the level of effort required.
Allowing users to continue to run old versions of the application. That, too, is sooo 1980's. Modern apps update quickly, and supporting every version of the application ever released is not tenable. That's what my father's COBOL application had to deal with, and he didn't enjoy it. I'm hoping technology has progressed.
Continuing to use Java Web Start. Until/unless Oracle changes its mind, Java Web Start is a doomed technology.
In May 2019 commented to watch the OpenWebStart project.
Now (October 2019) it is time to give OpenWebStart serious consideration. While not yet feature complete, a alpha beta release of OpenWebStart is now available for download under a "GPL with Classpath exception" license.
The OpenWebStart Technical Details page states:
OpenWebStart is based on Iced-Tea-Web and the JNLP-specification defined in JSR-56. It will implement the most commonly used features of Java Web Start and it will be able to handle any typical JWS-based application. We plan to support all future versions of Java, starting with Java 11. In addition to Java 11, the first release of OpenWebStart will also support Java 8.
The page goes on to state that OpenWebStart will support interactive installers with auto-update, and non-interactive installers. Some JNLP features will be supported, and it will include a replacement for the Java Control Panel. A more comprehensive list of planned features1 and their implementation status is provided in the feature table.
1 - If you have a requirement that is not on their feature list (e.g. jlink support), you could contact the OpenWebStart team, and offer a suitable incentive (e.g. money to pay developers) to implement the feature for you. They also offer commercial versions of the software for paying customers.
Disclaimer: I have no connection with the OpenWebStart project, the company (Karakun) or the project sponsors. This is not a recommendation.
I had a similar problem in a past project. We needed to migrate from Webstart to another technology.
The first approach was to install IcedTea. It is directly bundled with the AdoptOpenJDK Project.
But as far as I understood the problem, Java wasn't meant to be installed on the Client side like this anymore and we didn't want problems with all of our customers.
Our solution was then building an own specific Executable, which connects to the server, ask for enviroment settings from the server side, and then download and extracts the JLink Java. So we could use the old technologies and just wrapped it in an Executable.
Last thing done then was redirecting to the download location of the Executable when calling the jnlp-URL.
Do you use maven?
I've resolved my similar problem with maven (I need to update an EAR).
My main app (the ear package) has a pom.xml with listed the dependencies and repositories.
The dependencies have the <version> tag with a range (documentation) as in this example
<version>[1.0.0,)</version>
That means : get version 1.0.0 or newer of the dependency. (You can put also an upper bound to the version, [1.0.0, 2.0.0) so if you develope a new version, it is not used in old app)
In the repository section I added my personal repository.
Now, in the remote machine I need only to rebuild my ear package with maven : the compiler download the newer version of my jar and put it together.
You need a system to check if there are newer dependencies version and warn the user to update the app and also lock its work (you can't work if you don't update). Maybe you need a little app to make users do the rebuild process easily. It's 1990's but a lot of desktop-app works in this way
PRO
This schema can be used in a lot of different projects.
CONTRO
You need to build the app in the remote machine, so the client must have a JDK and access to your repository (like artifactory);
You must write code in different jars and add them like dependencies in the main archive.
You must change JAR version each time and publish on the repository (this could be a good practice)
I have built my google app engine app using version 1.8.8 but the production server hosted by google uses 1.9.11. I think this may be causing problems within my app since my app works locally but not on the production server. Is there anyway to change the version of the sdk that the production server uses? I can't seem to find any documentation on this.
No, you cannot define specifically which version of the SDK will run on the production servers. Typically, they run on the latest available SDK. If you are certain the that problems are caused due to the different versions of the SDK, I would propose to update your code accordingly.
I am going to develop on Google app engine platform in java and I don't know which eclipse download package I should get.
I don't know if the plugin supplied by Google has everything required and the classic package will sufice or if one could get some advantage downloading one of standard java packages.
Thanks in advance.
The plugin provided by Google Eclipse at https://developers.google.com/eclipse/ has everything that you need to develop GAE applications.
I am not sure what you are referring to as the classic package but if it is Eclipse Classic that you are talking about then it will suffice.
Few other points:
Make sure that you download the correct plugin version for the Eclipse version that you are using. Go to https://developers.google.com/eclipse/docs/download and use the version that matches your installed Eclipse version.
When you begin the process of installing the plugin, you will see a screenshot like https://developers.google.com/eclipse/docs/install-eclipse-4.2 where you will be given the option of what components to install. You can see that one of them is required but the rest are optional. I suggest that you go with selecting atleast the SDKs component.
All the best.
I developed some applications that uses google app engine and from my experience the eclipse plugin that google provides is sufficien but you need to install all the components of it.
I have some Python services and I have defined handler locations for them in app.yaml
I also have Java services and I have configured web.xml.
I want them both to be under same APP ID, e.g.
The Python app would be in http://myapp.appspot.com/pythonapp
The Java app would be in http://myapp.appspot.com/javaapp
So how can I accomplish this?
When I use GAE Java Eclipse plugin, it only uploads the Java service and deletes existing Python service.
When I use appcfg.py update it only uploads Python service and deletes existing Java service.
There is a hack: upload to different versions
You can have one instance version in Java and the other in Python. The default one will be visible to public via http://myapp.appspot.com.
You can access the other version (in browser or programmatically) viahttp://version.myapp.appspot.com, e.g. http://3.myapp.appspot.com
If you wan to acces both of them via the same URL, then you will need to proxy the request or do a redirect (if your client allows it).
There is no official way to use two runtime environments with one app. Jython is one way to run Python code in the Java runtime environment.
Depending on your needs, you can try using two different app versions with the same app ID. One version can use the Java runtime environment, and the other can use the Python runtime environment. Both versions would see the same datastore. You can address each app version separately using appspot.com URLs, though they're not pretty: http://version-id.latest.app-id.appspot.com Only one version can be the "default" version (http://myapp.appspot.com). This uses 2 of your 10 allowed versions, and you'll have to be careful to deploy each version with the correct version IDs. So it's not an ideal solution.
I'm sure that you can have only one app at same time, because it's different app servers/VMs for each type. I mean you can't upload different parts, can't have different sdk for different url on same app, etc.
Btw, you can try to use jython, it can interpret your Pythong code in Java project. I'm not sure that it's production ready (there was a lot of problems with it when i had tried it few years ago), but maybe it's helpful for your situation
As #splix said, deploying two app with different languages into the same appid seems to be impossible. So how about a workaround instead? Set a /pythonapp servlet on your Java app that will redirect all requests to mypythonapp.appspot.com via URLFetch.
The drawback of this workaround that come into my mind is that you are losing the information about the logged in user provided by the User API, so you would need to attach the information on the redirected request. Depending on the scenario of your app, I don't know whether this would be a show stopper or not.
EDIT: What I had in mind is what Peter suggested, using different versions rather than deploying them as totally different app, sorry that I mixed them up. Deployment to a different app would mean your Python app and Java app could not use a shared datastore.
The difference on my answer is that you could use URLFetches to forward the requests between different versions of your app. But having the redirection performed on the client's side as per Peter's suggestion rather than having it done on the server side as in my answer would probably be less hacky.