I use the Storm Apache in 1.0.0 version (java client - storm-core) and zookeeper in version 3.4.8. I check the version 2.0.0 is "significant improvements in terms of performance, new features, and integration with external systems". What is the steps needed to this upgrade?
Thanks all
As far as I know it's pretty much the same procedure as any other Storm upgrade:
Stop the Storm services (e.g. Nimbus, Supervisors) on the machine you want to upgrade.
Download and extract the new Storm release on the machine. Make any changes to storm.yaml that are appropriate to your environment (e.g. set nimbus.seeds)
Restart the Storm services using the new code
Check that everything appears to work in Storm UI, and that the new machine has joined the cluster
Repeat for the next machine in your cluster
You also want to update your topology jars. Point your dependency management at Storm 2.0.0 jars instead of 1.0.0. Most likely your topology will compile, if not you can probably find deprecation notices in the Storm 1.2.3 javadoc for any methods you might be using that are removed. These notices will likely also tell you what to do instead.
Finally instead of having a dependency on storm-core, you now want to depend on storm-client. The scope should be provided, same as in 1.0.0.
If I were you I would try this out in a test environment first, so you can catch any surprises before you try upgrading your production environment. You should also consider upgrading to 1.2.3 before you upgrade to 2.0.0, as that will let you see any deprecation notices in your code, and is likely to let you make any necessary changes to your code more gradually.
Related
I've been looking into hardening my Windows machine against the recent log4j vulnerabilities (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105). Fortuanetly, the only java application I have is minecraft.
On the official minecraft website, the developer claims that upgrading to v1.18.1 will fix the problem. I did that, but found that vulnerable versions of log4j (2.14.1) were still present at %APPDATA%/.minecraft/libraries and still contain JndiLookup.class. So it seems to me that the only thing that was the developers did was to set the log4j2.formatMsgNoLookups system property. This is, according to Apache, NOT sufficient (see https://logging.apache.org/log4j/2.x/).
I've tried:
updating log4j myself by manually placing the 2.17.0 version of log4j in %APPDATA%/.minecraft/libraries.
manually deleting JndiLookup.class from the 2.14.1-jar
overwriting the 2.14.1 version with 2.17.0
But each time, after launching the game, the old versions were back. It seems the game is ensuring validity and integrity of their third-party libraries. Normally, I would see this as a good thing, but in this case it's quite the opposite.
Has anybody managed to launch minecraft with safe versions of 2.17.0? Any tips on how to trick
An easy solution could be to run MinecraftForge instead (Download). They have addressed the Log4j security vulnerability by bumping to version 2.15:
https://github.com/MinecraftForge/MinecraftForge/commit/14e152579b8cbdb5f6c2e9ba089bf7971a1a727a
I've found out that it is very uncommon to choose a client version that is not the same as the server's version (for example in HBase client - server’s version compatibility).
On the other hand, I've got an answer about Camel compatibility that had been mentioning the Camel-HBase jar that I can find a fit version of the client's jar through downgrading it (for example https://mvnrepository.com/artifact/org.apache.camel/camel-hbase/3.1.0 for an old HBase version). But this answer also said that it is a bad thing to do (Can Apache Camel integrate with an old HBase version?). I wonder what is the solution if there is no such option for me to upgrade the HBase server (since it's not mine). Why choosing a lower Camel component (such as Camel-HBase) version is bad?
It's impossible to work otherwise since it will demand every integrated technology to be the most upgraded.
Sorry, obviously my answer you mention was not clear enough.
You absolutely can use an older Camel version whose dependencies match your specific Hbase-client version need.
But this decision hat some drawbacks:
You cannot upgrade your Camel application (version lock-in)
You cannot use another Camel component in the same application that has a more recent version because mixing Camel component versions (eg. camel-core 3.9.0 and camel-hbase 3.1.0) leads to lots of problems
The consequence of these points is that you probably have to "isolate" your Hbase integration in a Camel application that uses an old, "freezed" Camel version.
"Isolate" because as soon as you want to do something else that needs a newer Camel version, you have to build a new application that communicates with your hbase-integration through an API.
I hope, this answer makes more sense for you.
About your final statement
It's impossible to work otherwise since it will demand every integrated technology to be the most upgraded.
There are a lot of technologies that offer a much wider compatibility. Messaging clients like Kafka or ActiveMQ are wire-compatible with older server versions.
I need to monitor the Jetty threads and expose metrics to JMX in the runtime like the idle threads count.
My Jetty version is 9, and I found there is a document for Jetty 7/8 about jetty-monitor:
https://wiki.eclipse.org/Jetty/Reference/jetty-monitor
The feature is what I need, but it seems outdated. When I check the documentation for Jetty 9, I couldn't find the monitor-related feature.
https://www.eclipse.org/jetty/documentation/jetty-9/index.html
Anyone know what's the new approach to monitor
As far as I know, Jetty 9 still support classes of monitoring on the library. But It isn't exist for operational section of monitoring in the document.
If you wanna get that library with Jar file, you can visit to get that on maven repository to follow below link.
Maven repository
The features that jetty-monitor used to provide is now baked into Jetty 9.
Those values are present in JMX still.
Just make sure you have jetty-jmx enabled and you are good to go.
I'm using org.jboss.redhat-fuse/fabric8-maven-plugin in one my project but somehow the latest version is always behind.
Is there any reason why we are encouraged to use org.jboss.redhat-fuse/fabric8-maven-plugin for RH Fuse project? instead of io.fabric8/fabric8-maven-plugin
I'm the maintainer of io.fabric8/fabric8-maven-plugin.
org.jboss.redhat-fuse/fabric8-maven-plugin is Jboss's fork of upstream fabric8 maven plugin i.e io.fabric8/fabric8-maven-plugin. Jboss's fork may contain some jboss related patches as per it's requirements. I think it is used under FUSE internals like for Fuse Online. Usually it's synced with upstream plugin from time to time.
If you want to use plugin as a general purpose Kubernetes/Openshift plugin. I recommend to use upstream Fabric8 Maven Plugin. If you are working around FUSE related stuff, then maybe go with Jboss's fork since it's tried and tested. But I think upstream would also work fine.
We have a web application that is implemented in Java. It uses Maven to install various dependencies such as JavaMail, Gson, and so on.
Unfortunately, deploying and maintaining the project is a nuisance. We need to be aware that any of those dependencies might issue a security update, which means checking regularly for new versions. To make matters worse, we can't see any way that Maven can distinguish security fixes from other new releases. This means that we end up doing needless updates, which is a waste of time and could break something.
The server itself runs Ubuntu, and the situation there is far better. Apt installs urgent updates, but everything else waits until the next Ubuntu release. That's ideal because it gives us a stable but secure platform that we can build on.
Is there any way of making Maven more like Apt, so we can install security fixes but nothing else? If not, I'd be interested to know what strategies other people use for updating deployed web applications.
(We know about the maven-dependency-plugin. This plugin helps, because it can automatically find and update any dependencies which have newer versions. Unfortunately it can't distinguish security updates from normal feature releases, so we end up updating when we don't strictly need to.)
I did come up with a partial solution to this problem, but it doesn't use Maven directly. I implemented a script which scans the NVD database for new security exposures relating to products we are using. Every morning I get any new ones emailed to me, and I can decide whether they justify an update to our web application.
The downside of this approach is that smaller projects don't always issue CVE numbers for their vulnerabilities. We have to restrict ourselves to products that have a significant following, are backed by a large vendor, or have previously demonstrated a willingness to take part in the CVE process.