To be absolutely clear: The Apache HTTP server that is commonly used in the AMP,LAMP, MAMP,WAMP stack, is not java based, does not integrate or use any java components, and is not at risk.
This is a common enough misconception, in regards to Apache vs the Apache Software Foundation.
The Apache webserver is one of the oldest Free Open Source web servers. For the record it is written in c.
The original core contributors to the Apache HTTPD server, went on to create the Apache Software Foundation(ASF), which was incorporated as a non-profit to support the continued development of FOSS software. The ASF also authored their own License, that is comparable and competes with the GPL and MIT licenses often used for FOSS.
Over the years, the ASF has sponsored and brought many different types of software under their umbrella. These projects benefit from funding and support services provided to them by the ASF. At present there are something like 180+ individual software projects under the ASF umbrella. Here is a list by programming language.
Apache is a big player in the Java development space, with many important tools and java based projects under their umbrella. Log4j is just one of these projects, but it is often integrated into other java based software and systems via their java logging project.
Here's one quote to help understand the potential scope of the problem:
Anyone running an Enterprise or Java based system is a potential target, but there are also many pieces of java based software that are used by companies for the services they provide.
For example, note the mention above of "Solr" which is a popular full text indexing engine that many sites who aren't otherwise java based, may use. Apache also provides the Lucene engine, which is also Java based. Basically if you are running any sort of java based software server, there is a good chance that the log4j vulnerability is a concern.
For any company with sysadmin/devops/developers with a degree of competency, the log4j exploit vector can be quickly and easily closed using several techniques that vary by log4j version and environment. The problem is that there are many packages of java based software like Lucene & Solr, that the users may not realize are java based. They may come with a packaged JRE, or be running via an independently installed JVM.
The actual exploit requires crafted input that gets logged containing instructions which trigger java JNDI to download and run remote code. So it's a "remote code exploit".
If a server with a vulnerable installation or version of log4j doesn't have some sort of publically available listener, there isn't a vector for exploitation. For example, depending on the integration, your Solr or Lucene engine might not be at risk. It could depend on how or what you are indexing, and where the data being indexed comes from.
Many people are running java based editors like Eclipse or Netbeans, or any of the Jetbrains editors, in particular the very popular PHPStorm. What does Jetbrains have to say about this? https://blog.jetbrains.com/blog/2021/12/13/log4j-vulnerability-and-jetbrains-products-and-services/
I hope this helps clarify some things for people.