I changed the timeout of an activity. In aws doc, it says I must register a new version of that type in this case. But how to let the execution use the new version?
The decider schedules an activity using ScheduleActivityTask decision. Which requires activity version to be specified. So you have to change your decider code to use the new version of the activity.
If you are using the flow framework just change the activity version (in the #Activities annotation for the Java version of the framework) and redeploy both the activity and the decider code. More complex upgrade scenarious can be supported through overriding activity version during invocation by passing ActivitySchedulingOptions parameter.
Related
Is it possible to automate the updating of an app using Appium?
My scenario is that I need to install an older version of the app and in my test I have to install the newest version.
But the desired capabilities for appium:app is defined as the latest app. I was thinking that I can override this desired capability to be an older version first? But, for now, I am still not sure how to execute this.
How should I go about testing this?
Using "app" capability install the old version.
Then, use driver.installApp() to install the newer version. This will upgrade the app by default.
Note that you might have to cast the driver to use the installApp() command.
For e.g. if you are initialising the driver like below,
AppiumDriver driver = new AndroidDriver():
Then, you may have to cast the driver like below:
((AndroidDriver) driver).installApp();
Similarly for iOS,
((IOSDriver) driver).installApp();
The Appium's project lead has created a very good article on this topic for Android. You can read about it here: https://appiumpro.com/editions/9-testing-android-app-upgrades
I am using AWS Flow Framework for setting up SWF. SWF recommends bumping up versions of activities or workflows if backward incompatible changes are introduced. Can changing dataconverters be considered a backward incompatible change breaking workflow replay?
Dataconverters: https://docs.aws.amazon.com/amazonswf/latest/awsflowguide/dataconverters.html
Yes, it is going to break the replay. Replay is going to execute the workflow from the beginning and use DataConverter to deserialize activity results. If DataConverter changes then the activity result is going to change which might break workflow determinism.
BTW a change to an activity implementation that doesn't affect the activity input and output parameters is backwards compatible and doesn't require a version change.
What is the simplest way to migrate a Grails app developed in 3.0.4 to 3.0.6?
The grails documentation recommends to create a new app and migrate every component one by one. But there should be a simple way if we are migrating within version 3?
Any help much appreciated
I run a grails create-app to create a fresh install of the new version. I then copy the files from the new version over top of my older v3 version. It's then pretty simple using version control tools to check for changes that need to be merged. The following files will have some changes that need to be merged into my existing project files:
build.gradle
gradle.properties
To be safe I usually also copy over the following, though they are less likely to have changes:
gradle/
gradlew
gradlew.bat
grails-app/conf/application.yml
grails-app/conf/logback.groovy
grails-app/i18n/messages.properties
grails-app/init//Application.groovy
With version control it usually takes less than a few minutes to review and merge back any changes that need to be retained. I find the process fairly simple.
I think you refer to this documentation https://grails.github.io/grails-doc/latest/guide/upgrading.html which is really about grails 2.x to 3.0.x migration.
In the case you're already on 3.0.4 you can just look at the release note of the version to see what is new and if there's any impact. As you will see its a lot of bug fixes and the introduction of the new web profile to create REST specific applications.
Predictably, my app won't have changes in its data model in future updates, but just in case... will it be a problem to deliver the first version of the app without having set its Model Version, and then starting setting it in subsequent app versions only if migrations needed? Or should I deliver the first version of the app having already set a Model Version?
Thanks
Yes, maybe you don't need enable versioning in the first version.
BUT, for example, if you enable it in the second version, and forgot change CoreData initializing code?
I prefer add automatic version migrating since first version of app, even if I don't plan to change model
How to create a class dynamically in a Blackberry project that uses Eclipse plugin?
My requirement: Suppose on click of a button a new class with a given name should be created. Methods and fields should be added and
then I should make use of that class
object. Is this possible in Blackberry?
Below are the steps I have done.
Get third party jars like ASM, javassist
Try to use them in project
but, I am getting verification errors when deploy to the device. So, is there a native api in RIM or any other alternative?
BlackBerry Java does not support the full set of reflection capabilities that you would expect in Standard Java (J2SE).
So, you won't be able to dynamically create a class, add methods, and then call them.
For the most part, BlackBerry is Java 1.3. If you tweak your development environment, you can get access to some newer features at compile time. But, in terms of the runtime code, you're limited to 1.3.
Javassist is based on Java APIs that don't exist in the 1.3 runtime that BlackBerry has, so it won't be of much help :(
Hopefully, someone else will chime in, but I don't know that this is something that's possible on BlackBerry Java.