ASF Releases: Apache SkyWalking, Syncope, Traffic Server, Pulsar Client C++, ActiveMQ, Ant, Pulsar, Beam, Groovy

I recently built nerv-audit, a library on top of Hibernate Envers focused on vertical auditing. Most audit discussions focus on system-wide (horizontal) logs. But in practice, debugging usually comes down to a simpler question: 👉 What exactly changed in this entity? That’s where vertical auditing shines: • Clear, per-entity history • Precise diffs you can actually reason about • Less noise compared to aggregated audit streams • Better alignment with domain-driven design Instead of reconstructing state from a global timeline, you can directly inspect the evolution of a single entity with confidence. GitHub: https://lnkd.in/gSBi_ksN Curious how others approach auditing in their systems — vertical, horizontal, or a mix? #java #springboot #hibernate #ddd #softwareengineering

I recently diagnosed a challenging issue involving a scheduled notification service that performed perfectly during high-frequency tasks but failed during daily batch processing on Heroku. The Symptom The application would throw a java.lang.StackOverflowError specifically within the Hibernate HqlBaseParser whenever the volume of records to be processed exceeded a certain threshold. The Root Cause: Recursive Predicates The original implementation constructed a dynamic Specification inside a loop, chaining predicates using .or(). • Small Data Sets: With few records, the resulting “tree” of predicates was shallow and processed successfully. • Large Data Sets: During daily runs, the backlog created hundreds of nested .or() clauses. Because Hibernate uses recursion to parse these deeply nested specification trees, it eventually exhausted the Thread Stack Memory (which is strictly limited in environments like Heroku). The process would crash before even reaching the business logic for sending emails. The Solution: Flattening the Query The fix involved moving away from the recursive .or() loop and instead using the IN operator. By extracting the necessary IDs into collections first, I was able to create a flat, iterative query structure. Key Takeaway Avoid building large, nested predicate trees within loops. Transitioning to IN clauses or batching your specifications not only prevents StackOverflowError but also generates cleaner, more performant SQL. #Java #SpringBoot #Hibernate #JPA #SoftwareEngineering #BackendDevelopment

🗞️ Here's your weekly ASF release roundup! 🗞️ 👉 Apache TsFile 2.2.1 is now available for download: https://buff.ly/DXMIAz9 TsFile is a high-performance columnar storage file format designed for industrial time-series data, featuring multi-language interfaces, high compression ratios, high read/write throughput, and fast random access capabilities. 👉 Apache Storm version 2.8.5 is now available for download: https://buff.ly/6KqmSOX Apache Storm is a distributed, fault-tolerant, and high-performance realtime computation system that provides strong guarantees on the processing of data. 👉 Apache ActiveMQ 6.2.2 has been released. This is a maintenance release on the ActiveMQ 6.2.x series, including: ✅️ improve FactoryFinder validation ✅️ fix Jolokia runtime ✅️ upgrade to Jackson 2.21.1 You can download ActiveMQ 6.2.2 here: https://buff.ly/FVMMdXs 👉 Apache ActiveMQ 5.19.3 has also been released and is now available for download: https://buff.ly/FVMMdXs 👉 Apache Tika is a toolkit for detecting and extracting metadata and structured text content from various documents using existing parser libraries. Tika 3.3.0 is now available for download: https://buff.ly/wdoXuIj 👉 Apache Tomcat 10.1.53 is now available for download: https://buff.ly/TUlWy4H Tomcat 10 is an open source software implementation of the Jakarta Servlet, Jakarta Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations specifications. 👉 Apache RAT is a release audit tool. It improves accuracy and efficiency when checking releases. It is heuristic in nature: making guesses about possible problems. It will produce false positives and cannot find every possible issue with a release. Apache Creadur RAT 0.18 is now available for download: https://buff.ly/LWBl7qI 👉 Apache Maven Daemon version 1.0.5 is now available for download: https://buff.ly/ClFCVgC This release provides binaries based on Maven 3.9.14. This release is functionally equivalent to 1.0.4, the only change is added Linux Arm64 support. 👉 Apache ShardingSphere ElasticJob-3.0.5 is now available for download: https://buff.ly/OQzZbT2 ElasticJob is a distributed scheduling solution. Through the functions of flexible scheduling, resource management and job management, it creates a distributed scheduling solution suitable for Internet scenarios, and provides diversified job ecosystem through open architecture design. It uses a unified job API for each project. Developers only need code one time and can deploy at will. #opensource #data #machinelearning #cloudcomputing #java #NoSQL #webserver #hadoop

While debugging a Hibernate issue recently, I came across something interesting 👇 `org.hibernate.ObjectNotFoundException` — a small error with a big lesson. At first glance, it looked like a typical lazy loading problem. But the actual root cause was deeper. 🔍 What was happening? Hibernate created a proxy for a related entity, but when it tried to initialize it, the corresponding row didn’t exist in the database. 👉 In short: The application assumed data integrity, but the database told a different story. ⚠️ The tricky part? The exception wasn’t thrown during query execution. It appeared during debugging when `toString()` was triggered on a proxy object. 💡 Key learnings from this: 🔹 ORM frameworks don’t guarantee data consistency — your database does 🔹 Lazy loading can hide issues until runtime (or even debug time) 🔹 Using Lombok `@ToString` blindly on entities can backfire 🔹 Circular relationships (OneToMany ↔ ManyToOne) can lead to unexpected behavior 🛠 What helped fix it: ✔ Verifying referential integrity at the database level ✔ Avoiding unnecessary eager access during debugging ✔ Restricting `toString()` to only essential fields ✔ Using LEFT JOIN fetch where relationships may be optional 🚀 Takeaway: Most production issues are not about complex logic — they are about mismatches between your assumptions and actual data. Always trust your database more than your ORM. #Java #Hibernate #SpringBoot #BackendDevelopment #Debugging #SoftwareEngineering #Production #ProductionIssues #ErrorHandling

🚀 DevOps Day 24 | Multi Container Deployment | Java + MySQL | Part 2 After learning Docker Compose basics, I moved into real production architecture. Today I deployed: • Java Backend Application • MySQL Database • Multi Container Setup This is where DevOps becomes real-world engineering. My application.properties: spring.datasource.url=jdbc:mysql://mysqldb:3306/bank spring.datasource.username=bankuser spring.datasource.password=bankpass123 Notice something interesting? Instead of localhost, I used: mysqldb Why? Because Docker Compose automatically creates internal networking between containers. Now My Docker Compose File: version: '3.8' services: mysqldb: image: mysql:8 container_name: mysql environment: MYSQL_ROOT_PASSWORD: admin@123 MYSQL_DATABASE: bank MYSQL_USER: bankuser MYSQL_PASSWORD: bankpass123 volumes: - ./mysql_data:/var/lib/mysql backend: image: bank container_name: bankapp build: context: ./backend environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysqldb:3306/products SPRING_DATASOURCE_USERNAME: bankuser SPRING_DATASOURCE_PASSWORD: bankpass123 ports: - "8080:8080" depends_on: - mysqldb Key Learnings: mysqldb Database container backend Java application container depends_on Ensures MySQL starts before Java environment Inject runtime variables ports Expose service externally This setup allowed my Java application to communicate with MySQL automatically. This is exactly how Microservices Architecture works. And honestly… this felt like real DevOps work. Part 3 Coming Next Volumes + Production Level Data Persistence GitHub Repo https://lnkd.in/gjw9Fuxe #DevOps #DockerCompose #Java #MySQL #Microservices #CloudEngineering

If you are still using Hibernate’s ddl-auto=update in production, you are playing a dangerous game with your data. While JPA can automatically map entities to tables, relying on it for production is a liability. A simple property rename can lead to unintended column drops or suboptimal data types. To build a professional CI/CD pipeline, you need traceability and reproducibility—not framework "magic." The Versioned Migration Strategy This is where Flyway shifts the paradigm. Instead of guessing the state of your schema, Flyway treats database changes like code. Every migration is a versioned, immutable SQL script stored alongside your application. This gives you a definitive "git log" for your database, ensuring every environment—from local to production—is in perfect sync. Seamless Integration Spring Boot handles the heavy lifting by executing these scripts automatically during startup. Whether you use a JPA-first approach (generating scripts from entities) or a DB-first approach, the framework ensures your schema is validated before the application even starts. It’s a clean, automated way to eliminate "schema drift." The Value Professionalizing your database management isn't just about safety; it's about making your deployment pipeline predictable. It moves the responsibility of schema integrity away from manual intervention and into the automated heart of your application. Do you prefer the "straight SQL" simplicity of Flyway or the structured power of Liquibase? #SpringBoot #Java #Flyway #DatabaseMigration #CleanCode #SoftwareEngineering #BackendDevelopment #Fullstack #DevOps #Programming #Django #Python

Java Spring Boot Annotations in a Nutshell https://lnkd.in/g7BmyE3E A technical overview of the essential Java Spring Boot Annotations, serving as a comprehensive "nutshell" guide for modern backend development. As Spring Boot continues to dominate the enterprise ecosystem, mastering its annotation-driven configuration is critical for building scalable, decoupled, and maintainable microservices. => Core Framework Annotations: Analyzing @SpringBootApplication, @Component, and @Bean for managing application context and dependency injection. => Web and REST Integration: Demonstrating the use of @RestController, @RequestMapping, and @PathVariable to streamline API development. => Data and Configuration: Leveraging @Service, @Repository, and @Value to enforce clean architectural layers and externalize properties. #codechallenge #programming #CODE #Coding #code #programmingtips #java #JAVAFullStack #spring #springframework #Springboot #springbootdeveloper #Maven #gradle #annotations #controller #service #dependencyInjection

Spring Boot's OSIV default turns your JSON serializer into a hidden query engine I'm building a personal finance platform with Spring Boot 3.5 + Java 21. The first thing I disabled was Open Session in View. Spring Boot ships with spring.jpa.open-in-view=true. That means Hibernate keeps a database connection open through the entire HTTP request - including JSON serialization. When Jackson walks your entity graph to build a response, every uninitialized lazy relationship triggers a database query. Your serializer is now executing SQL. In a load test with HikariCP's default pool of 10 connections and around 150 concurrent requests, this is where things break. Each request holds a connection for the full request lifecycle instead of just the service layer. The pool exhausts, threads queue up, and response times spike. The tricky part is that it works fine in dev when you're the only user. Disabling OSIV forces you to think about what data you actually need. You fetch it explicitly in the service layer with JOIN FETCH or projections, map it to a DTO, and the connection goes back to the pool before serialization even starts. It's more code upfront but the data flow becomes visible instead of hidden behind proxy magic. The second thing I changed was ddl-auto. Hibernate's update mode can generate schema changes automatically, but it can't rename columns, drop unused indexes, or migrate data. It produces a schema that looks right but drifts from what you intended. I use validate with Flyway migrations instead - every schema change is an explicit, versioned SQL file. If the code and the database disagree, the app refuses to start rather than silently diverging. These two defaults share the same problem. They hide complexity that surfaces as production issues. OSIV hides query execution. ddl-auto update hides schema drift. In both cases, making the behavior explicit costs more effort early but removes an entire class of debugging later. #SpringBoot #Java #BuildInPublic #BackendDevelopment

Stop putting Lombok’s @Data on your JPA Entities. I know it saves time. You create a new Entity, slap @Data at the top of the class, and instantly get all your getters, setters, and string methods without writing boilerplate. But after 9 years of debugging Spring Boot applications, I can tell you this is one of the most common ways to silently crash your server in production. Here is why Senior Engineers ban @Data on the database layer: 1. The StackOverflowError Trap If you have a bidirectional relationship (like a User entity that has a list of Order entities, and an Order points back to a User), @Data generates a toString() method that calls the toString() of its children. User calls Order, Order calls User, and your app crashes in an infinite loop the second you try to log it. 2. The Performance Killer @Data automatically generates equals() and hashCode(). In Hibernate, evaluating these on lazy-loaded collections can accidentally trigger a massive database query just by adding the entity to a HashSet. You suddenly fetched 10,000 records without writing a single SELECT statement. The Senior Fix: Keep your database entities explicit and predictable. Instead of @Data, just use @Getter and @Setter. If you absolutely need a toString(), write it yourself or use @ToString.Exclude on your relational fields to break the loop. Lombok is an amazing tool, but using it blindly on your entities is a ticking time bomb. Have you ever taken down a dev environment because of an infinite toString() loop? Let's share some war stories below. 👇 #Java #SpringBoot #Hibernate #CleanCode #SoftwareEngineering #BackendDevelopment #LLD #SystemDesign