Am I correct in observing that Corda 1.0 is using Kotlin plugin 1.1.4? Just out of interest I tried to use 1.1.51 and ran into defaultWhiteList loading issues...although I'm not entirely sure why tbh...suspect classpath loading issues on the ServiceLoader.load in DefaultKryonCustomizer?? Anyway, when I revert to 1.1.1 (am still on M13) all is well again.
Just wanted to gain some understanding around why an inadvertent upgrade of the Kotlin plugin to 1.1.51 would cause issues with the serialisation default whitelist loading?
Thanks
A somewhat non-answer, but I'll try anyway: As we see the kotlin language mature and as Corda uses quite a wide feature set of what's available in kotlin, it doesn't surprise me that sometimes the frequently published newer versions of Kotlin don't work with older versions of Corda - especially if they make some internal changes to objects then I'm not surprised we see kryo serialisation issues. We publish the recommended / supported version of kotlin in the constants.properties file which, for release 1, is as you've correctly pointed out, 1.1.4 (which can be confirmed here: https://github.com/corda/corda/blob/e564edaa572a011869d692b05518113632363216/constants.properties ).
It does look as if we have updated this for the forthcoming v2 release to 1.1.50 if that helps. It may be a little late in the day to bump this to 1.1.51 though (a fair amount of testing and QA has already been performed).
Related
I am currently fetching the JS SDK from "https://www.gstatic.com/firebasejs/5.4.0/firebase.js". I want to make sure that my setup that doesn't change. Can I assume that Firebase would not change this file (or any version for that matter) without changing the filename?
Never assume that internal files won't change without changing the file name. There is a good chance that methods inside that file may indeed get changed to match with current changes or upgrades in technologies. Usually, though, major developers will do their best to insure the changes will not break anything in legacy files.
Firebase practices semantic versioning. This means that minor versions are backwards compatible, while major versions may contain breaking changes.
So version 5.4 should be drop in compatible with all 5.x versions.
But if you upgrade from a 4.x or lower version, you may have to make changes.
Whether this is actually needed depends on what products you use, and the changes to those products between the versions. The older the SDK you're upgrading from, and the larger the number of products you use, the higher the chance that you'll need to upgrade.
If you want to check what has changed, check the detailed release notes here: https://firebase.google.com/support/release-notes/js
I've been looking at options for persistence when using RxSwift and Realm was looking attractive due to it's relative simplicity and the availability of some extensions in the community repo.
Unfortunately although I can get Realm and RxSwift working nicely in Xcode 8b6, things of seriously wrong as soon as you try to connect them together as RxRealm does not currently compile (there seems to be more going wrong with it than the Grand Renaming as far as I can tell).
Is there a workaround that is reliable? I can't believe for a moment that there isn't, I just can't find a resource at present. I was thinking of converting the Result object into an Set or Array and making this Observable but. I'm not sure if the contents (Realm Objects) are going to be handled correctly. Knowing my luck, I suspect not!
There's a Pull Request towards the RxRealm project adding Swift 3 support: https://github.com/RxSwiftCommunity/RxRealm/pull/26
I suggest you try using that.
More generally, targeting an Xcode beta will by definition give you a less stable software ecosystem, since no one is submitting apps with that and it's a moving target (often with weekly breaking changes). So if you want stable software, use stable tools. Realm and RxRealm both support Swift 2.2 quite well, so using that will give you the best experience.
After reading the documentation on the website, I was very impressed with how easy it is to implement and use. However, I also noticed that it hasn't been officially released yet and it is still in beta.
I will soon start a new iOS project and I was wondering if realm is "stable" enough for production use. As many of you know, CoreData is a pain in the ___.
Thanks,
According to the folks at realm, the framework has been used in production, however, developers should expect the API to evolve as this is still in a beta stage.
We've recently had several hacks on our one server. We've been advised to upgrade all scripts. The problem is, the Drupal installations. Upgrading these are a massive task. I would like to know, out of fellow Drupal users, in your experience, how unsafe is it to remain on a say version 6.10 as apposed to upgrading 6.28 (the latest)? Is there a point at which you can say: this is really too old now and an upgrade is absolutely necessary?
I'm not too worried about the modules, my concern is the Core Drupal installation. Does it ever become a security risk, or can you stay on the older versions?
"Upgrading these are a massive task"
Not necessarily! I find using git a pretty safe way to deal with such upgrades.
My basic workflow is usually to:
- create a repository with the current Drupal version.
- download the latest core version
- rsync the current version with the latest core version
- update the repository
As expected, I do all of the above on my local version, after checking that everything is working fine. I update the remote repository, then update the actual live site from git.
If you're not familiar with git, basic tutorials are easy to find online. The idea here is not to explain the process in details, rather to send you in the right direction. You will find that it's a pretty flexible workflow, a great way to update modules and generally any type of code.
I'm trying to find 1, just 1, working sample project for Red5 that's updated to work against the latest 0.9 release without missing jars and other nonsense.
Right now, it's at v0.9 and the libs are different from other versions. They have 5 pathetic examples on their website, but all were built with the older versions. For these 5 old examples, I could use the Add External JARS feature to try and add libs from previous versions, they don't mention which versions they were built against and I'm not going to try each previous version to see which works (I already did and nothing works). They don't seem to be putting any effort into updating or marketing their open source project.
Anyone who's more intelligent and can shed some light on behalf of these fools?
What sorts of issues are you having? What sorts of projects are you trying to build?
I'm by no means an expert on this - and I admit that the lack of documentation is pretty frustrating.
However, I just downloaded their latest, installed it and got the olfa demo running pretty seamlessly.
The source for the demos are available here, and I use these to work out what I need.
http://www.smartfoxserver.com/ makes use of red5 in someway. Perhaps you can find something useful in their (well documented) examples, good luck.