We are evaluating reactor library for using it in our project. Our project was backed by spring context. So we needed a tool to build event-driven application which has the spring support.
Also our main area of focus was on ability to composing sequence of asynchronous events (Streams & Promises). In certain other use cases we might be in need of publisher/subscriber model or running long running processes asynchronously.
As I was evaluating, I noticed some of the following the latest released reactor-spring version is v1.1.3 with dependency on reactor-v1.1.3 which we could use.
But I also noticed the there’s reactor-v.2.0.0 (under development) which had quite a bit of changes especially in the area of Streams and Promises.
Please suggest me if it is a good idea for going with reactor-v1.1.3 with spring support or should we wait for reactor-v2.0 if we have to use more of Streams and Promises.
If we go ahead with reactor-v1.1.3.RELEASE how much code changes might be needed to get ourselves upgraded to v2.0.0.
I also wanted to check if we have any branch of ‘reactor samples’ for reactor-v1.1.3/v1.1.4. As of now I could see only one master branch available which has been updated to use reactor-v2.0.
Do we have the reactor API for latest release v1.1.4. Currently the API (https://reactor.github.io/docs/api/) points to Reactor 1.1.0 Release.
Where can I find the reactor-core-2.0.0 codebase? I am finding difficult to locate.
As I am new to this library, please feel free to correct me if any of my mentioned points/questions were incorrect. Thanks.
If you're starting new development, definitely go with Reactor 2.0. It's mainly the substantial improvements in the Stream and Promise APIs which resulted in having to bump the major version number. Differences in the rest of the codebase are pretty minimal. Converting between 1.1 code and 2.0 code requires some package renaming and a few tweaks here and there (like eliminating the use of the Deferred object in Stream 1.1).
The other major change that justifies a major point release bump is the implementation of the Reactive Streams specification. It's out of the scope of this question to discuss it further but it is an important part of Reactor moving forward. Being able to natively integrate with Akka Streams, Ratpack, RxJava, and other libraries that already (or will shortly) implement Reactive Streams is a huge benefit to Reactor 2.0.
The reactive-streams branch contains the code for Reactor 2.0. M1 is coming shortly and we'll start the process of updating the samples, though as you've noticed, some components like Spring support have already had to be bumped to Reactor 2.0 since they're relied on in some major almost-production applications.
Related
I have problems finding useful pentaho ETL tool information, is this tool dying?
What are the alternative tools/platform>
In short, yes, Hitachi Vantara aquired the suite and they aren't giving much love to it. They've just released the 9.2 version, but I don't have much faith in having a lot of improvements for the CE version, maybe some more for the paid version, but I don't think there's going to be much either, they killed the old forum and the new community they created is deserted.
For the Data Integration (ETL) part of the suite, you can go to apache-hop (https://hop.apache.org). A bunch of Kettle (the original name for the Pentaho Data Integration tool of Pentaho Suite) developers are actively modernizing and much improving the old code: it mostly works with Java 11, they are staying in Java 8 because of dependencies of the Beam plugins, the dependencies with old deprecated libraries are gone, for now there's not a lot of new functionality, just migration with some new features, but even if there isn't a 1.0 version yet, it is much advanced and some PDI/Kettle users are beginning to transition their production environment to this new tool.
There's a migration utility for the old jobs and transformations in PDI to workflows and pipelines in Hop. After applying the migration tool you're going to need to check and modify things yet, DB connections are possibly going to need some work afterwards, and a few of the old steps aren't available in Hop (Formula step is the one that most affect me) but in general the utility saves a lot of work.
New things in Hop:
Built with the idea of supporting project and environment configuration, so paths and information that are project/machine dependent work with different configurations, you just change the project or environment information and everything works.
Much better metadata injection support, PDI/Kettle still had a lot of steps with properties not available for metadata injection, and in the migration they have added it
Night mode
Much lighter, quicker start (PDI takes a long time just to initialize) and you can get rid of steps/plugins that you don't need if you just need a thin client to perform one task.
Hop-web
I'm working with a Grails application version 2.2.4 and I need a procedure for upgrade to latest version (I hope it can be possible). I have thought as a first step to follow the indications of the official site, but that let me to upgrade to version 3.
I'd like to know if anyone already did it or have experience about that. How long take it?, the process and the main problems.
Many thanks in advance.
I think you need to follow both upgrade instructions. the one for 3.x and the 4.x.
start with the 3.x and them move to the 4.x changes.
Another approach I think may be better is to start an empty 4.x application and then start moving you code there. also check first that all the plugins that you are you sing have 3+ version.
The effort required to upgrade can change massively depending on multiple factors, including the size of the project, the quality of the original code, were plugins used and if so have they been updated or will the functionality need replacing, were deprecated taglibs used, e.g remoteFunction etc. etc.
There is not a great deal of difference between 3.x and 4.x so it makes sense to upgrade to 4.x.
Tackle it in stages from the basis of a new project, attempting to rebuild the project between stages.
Reestablish configuration, you don't have to use application.yaml (the default in 4.x) so can create an application.groovy with the same parameters as per your old project.
Move over domain objects but use a new database URL, compare the schema's between the old db and new db to ensure the database is the same. Unless you don't rely on GORM to recreate/update the schema.
Move over any other source and command objects ensuring the project will build. You may need to modify buildconfig at this stage to bring in dependencies and plugins.
Move over services, ensure all compiles and make sure transactions are behaving as intending.
Move over controllers ensuring any tests run successfully.
Move over the views.
Hopefully if the project is still building at this stage, you can run it!
Noticed that there is a 2.0 version of the Spring IO Platform available as a snapshot. I am looking to understand what might be driving the major version number change. Can someone with better insight into the changes share the themes here (or point to somewhere where this is better documented)?
Look at the "Upgrading" section of the documentation: http://docs.spring.io/platform/docs/2.0.0.BUILD-SNAPSHOT/reference/htmlsingle/#upgrading-removal
Some dependencies were removed, which leads to a major version, since it's a breaking change.
I really love Grails but I was wondering how to get the performance benefits of Groovy 2.
The question is how to configure the development and production environments in order to get that "close to Java" performance boost.
So, if I setup:
* JDK 7
* Groovy 2 (indie JAR to use invokedynamic)
* Grails 2.2
are there any guidelines in order to really speed my webapp out-of-the-box?
And do I need to do any re-factoring in my Grails webapp codebase? I mean that dependency injection stuff like referencing services in controllers should be statically compiled or should I keep writing code as the docs say?
ps: I guess Groovy #CompileStatic and Grails might be a relevant question...
It depends on what might be slowing your web application down :) I know "it depends" is so often the answer, but it's still true.
Anyway, I've asked around and it seems that Grails and invokedynamic won't go together just yet. The reloading agent needs updating and there may be problems with the cglib/asm libraries used by Hibernate.
Regardless, internally Grails is making more and more use of #CompileStatic (for the stuff that wasn't already written in Java), so unless your app is doing a lot of work itself, you're unlikely to see a big boost with invokedynamic.
It would be useful to have some official information on this, but it's not out there right now.
Is DWR a dead project? It does not appear to be under active development. The latest 3.0 release appears to be stalled. I'm specifically wondering if there are going to be maintenance releases of DWR 1.x or 2.x or is 3.0 is ever going to be released.
BTW. I asked this question on one of the DWR mailing lists and did not get a response.
Well, the 3.0 version is taking a while to get released, but it is nonetheless very stable.
We are using it in our production environment and we do did encounter any issue so far (2+ years in use).
Important issues on 2.0.X are fixed BTW. (seems that currently there are no major issues on 2.0.X).
BTW. I asked this question on one of the DWR mailing lists and did not get a response.
We had issues before (other version) and those were handler very quick.
Update Dec/2015: V3.0.1 released
Seems like it, I have used DWR like a year back and there is no release since then.
Their version 3 is still on RC (release candidate) and from my understanding of versioning, it is not stable or a general acceptance.
I would say move on... pass DWR. Pass Java too if you can ;)