This blog aims at giving some pointers in order to address the challenge related to the switch from `javax` to `jakarta` namespace. This is one of the biggest changes in Java of the latest 20 years. No doubt. The entire ecosystem is impacted. Not only Java EE or Jakarta EE Application servers, but also libraries of any kind (Jackson, CXF, Hibernate, Spring to name a few). For instance, it took Apache TomEE about a year to convert all the source code and dependencies to the new `jakarta` namespace. This blog is written from the user perspective, because the shift from…
Read More
Introduction If you’ve been following tech news over the last couple of days, you’ll very likely have heard about CVE-2021-44228, or “Log4Shell” as it has become known. This particular vulnerability affects Apache Log4J2, a Java logging framework. Tomcat, TomEE, and ActiveMQ themselves do not ship with log4j2, so running out-of-the-box with their default configuration they are not vulnerable to this issue. However, before you breathe a sigh of relief, you should be aware that applications deployed on either TomEE or Tomcat can include additional Java libraries bundled inside. Any jar file included in a web application’s WEB-INF/lib directory will be…
Read More
While working on Jakarta EE 10 certification (See announcement Apache Tomee Jakarta EE certified after 10 years, Apache TomEE implemented Jakarta Security specification. Currently, there is only one implementation used in Glassfish and used by all the other vendors for Jakarta Security. In TomEE, we decided to create an alternative to bring some diversity, and have an Apache implementation. What is Jakarta Security? Jakarta Security defines a standard for creating secure Jakarta EE applications in modern application paradigms. It defines an overarching (end-user targeted) Security API for Jakarta EE Applications. Jakarta Security builds on the lower level Security SPIs defined…
Read More
There are many blogs explaining how to get Jakarta Security on Tomcat using all sorts of libraries and wiring everything manually. So many opportunities to get it wrong, if you are evaluating or currently using Apache TomEE. In TomEE, the good news is that, like JAX-RS, CDI or Bean Validation, Jakarta Security is out of the box ready to be used like Servlet, and CDI for example. This blog is a high-level view so you have the big picture of the technologies and how they interact with each other in the security landscape. The goal is to be able to…
Read More
Twenty-four years ago, in May of 1996, Sun Microsystems announced that they were developing the server-side equivalent to the Java applet, the Java Servlet. Since then, the Servlet API has maintained a prominent position in the enterprise Java ecosystem.
Read More
Our support customers will sometimes ask, "What is the difference between Tomcat and TomEE," but that’s not really the right question. It’s like asking which is better “Omelets or Eggs” or “JSP or Servlets”. You can’t have the first one without the second. TomEE is Tomcat Plus It’s easier to think of TomEE as the same thing as Tomcat plus some bells and whistles, because TomEE is built on top of Tomcat. Specifically, TomEE 8 is the complete Tomcat 9 distribution plus Jakarta EE 8 (formerly Java EE 8) specific APIs. Tomcat is a powerful and hugely popular Java web…
Read More
Tomitribe’s David Blevins and Jonathan Gallimore join Sonatype to discuss and explain the top 5 Tomcat security vulnerabilities.
Read More
Tomitribe’s Jonathan Gallimore (@jongallimore) explains how easy it is to exploit a simple configuration vulnerability in Apache Tomcat and take over your entire server. He also explains how easy it is to prevent this from happening with a simple configuration change. This is an older exploit but one that may not be patched on your own installation. Watch the video to ensure you are protected! Tomitribe’s Enterprise Support service works with Sonatype to monitor all reported vulnerabilities to Tomcat, TomEE, and ActiveMQ to help protect our customers from malicious hackers. Learn more about how we help protect our customers here.
Remote debugging is a common practice for troubleshooting issues in software development. If you are using Tomcat or TomEE with Docker containers as part of your stack you can find various techniques to enable debug capabilities in these types of containers: 1. Create a custom Docker image by extending an existing official one 2. Extensive customization of CATALINA_OPSTS However, both approaches require extra steps in some scenarios. Below I share the simplest method I have used to do remote debugging in Apache Tomcat and Apache TomEE with a Docker image: $ $ docker run -it -p 8080:8080 -p 8000:8000 -e…
Read More
El debug remoto es una práctica común para investigación de problemas de microservicios. Si estas utilizando contenedores Docker Apache Tomcat o Apache TomEE, en la web puedes encontrar varias técnicas como lo son: 1. Extender una imagen oficial y personalizar 2. Utilizar personalización extensiva de CATALINA_OPTS Sin embargo ambos enfoques requieren extra pasos aplicables para algunos escenarios. A continuación les comparto la forma más sencilla que he utilizado para poder hacer debug remoto en Apache Tomcat y Apache TomEE: $ $ docker run -it -p 8080:8080 -p 8000:8000 -e CATALINA_OPTS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000" tomcat:9.0.17-jre11 Anatomía de las opciones utilizadas: docker run Comando para…
Read More
