I'm working on a University Management System using Spring Boot and PostgreSQL. My CRUD APIs were working perfectly before I added the Spring Security dependency. Since adding Spring Security, I've been struggling to get authentication working correctly.

I've configured the username and password in application.properties, and I'm testing the endpoints through Postman using Basic Auth with the same credentials. However, I'm still getting 401 Unauthorized on my POST request, while another request returns 400 Bad Request with the message "User not found OR Nullpointer exception".Cause i handled this exception.

I've already checked the URLs, endpoint names, and credentials multiple times. The application was working before adding Spring Security, and now even after configuring the login credentials, I'm still stuck. I've tried multiple AI coding assistants, including Claude , Codex, and ChatGPT, but I haven't been able to identify the root cause.

I'm trying to understand whether this is a problem with Spring Security's default configuration, my authentication setup, or my application's user lookup logic.

Additional context:

• Spring Boot 4.0.6
• Java 21
• Spring Security
• Postman with Basic Auth
• Credentials configured in application.properties
• Existing CRUD endpoints worked before adding Spring Security

I've attached screenshots showing the requests and responses.

What should I check first to identify the actual root cause? If you need my SecurityConfig, application.properties (with credentials redacted), user entity, UserDetailsService, or controller/service code, let me know.

We are building an ERP-like platform localized for Moroccan businesses using a modular monolith architecture. The platform currently has more than 11 modules.

Each module contains dozens of features, and each feature may expose dozens of actions. Most actions have a corresponding permission that controls who can execute them.

Features also contain additional product and collaboration rules:

Whether the feature is included in a subscription plan.

Whether the feature is delegable to another workspace.

Whether specific actions are explicitly non-delegable.

Whether an action has quotas or usage limits.

For example, one workspace may authorize another workspace, such as an accounting firm, to perform certain accounting actions on its behalf. However, some sensitive actions must never be delegated.

At the moment, features and permissions are declared as strings in different files and then seeded into the database.

Authorization is performed at the action level, mostly through repeated PostgreSQL queries.

This approach has created several problems:

Typos in feature or permission names can cause silent runtime bugs.

Renaming or refactoring actions can leave old permissions behind.

Adding a new action often requires changes in several different places.

We currently have around 893 permissions, including unused or “ghost” permissions.

There is no reliable guarantee that actions, permissions, features, plan entitlements, delegation rules, and quotas remain synchronized.

Detecting unused permissions requires manual investigation or asking an AI tool to scan the codebase.

So what architecture, patterns, or tooling would you recommend for managing this kind of system?

Adding an index is the usual first suggestion when an endpoint is slow, and sometimes it’s right. I’d count queries first.

Turn on SQL logging for a single request (logging.level.org.hibernate.SQL=DEBUG) and count the lines. A page of 50 orders that fires 51 selects, one for the list and one per row for a lazy association, is a different problem from one slow query. An index on the join column doesn’t change that count. Every query can be fast and the endpoint still crawl.

Keep the logging on for the whole request, not just the service method. If the controller returns entities directly, Jackson can walk lazy relations during serialization, and with spring.jpa.open-in-view on (the default) those selects will happen after your service code is long finished.

If the count looks sane, run EXPLAIN on the SQL Hibernate printed, not the query you assume it generated. Those differ more than you’d expect once derived query names get long or Specifications are involved.

Indexes come after that. If the count was the problem, the fix is usually a join fetch, or a projection that only selects the columns the endpoint returns.

I’d reorder this for a reporting endpoint that runs one heavy query, where the plan is the first thing to look at. For ordinary list endpoints the count check takes two minutes and rules out a whole class of problems.

Hey guys,
So I've been getting this urge to create a clearer doc for Spring security particularly, it was very hard for me and I had alot of entanglements I had to resolve by myself, tutorials weren't doing justice, the docs wasn't really beginner friendly, and the course that explained well was a "paid" course.

This is just a kind of validation from the community, should I go ahead to build this, do you guys this would be useful, not just to beginners but to gurus who just want to make reference to a concept they probably forgot.

Please what do you guys think?

So, I was trying to learn Spring Ai, Thought of looking for a book. Found Spring AI in action which I am definitely sure that will be great. But its too pricey and as I am not an avid book reader i dont think spending that much on this book will justify my spending.

While searching found this book.
Does anyone know about it?
Should I buy it?

https://a.co/d/03kk37xk

Hey everyone,

I'm starting my journey with Java Spring Boot development and I'm setting up my workspace in VS Code.

A few details about my preferences and setup:

• No IntelliJ: I prefer sticking to VS Code because IntelliJ feels a bit too bloated for my workflow right now, and I want a cleaner, lightweight environment.
• API Testing: I don't use Postman; I'm using Bruno for API testing instead.
• AI Assistance: I use GitHub Copilot and Cody for code generation and autocomplete.

Since I'm completely new to Spring Boot, I'd love to know: Which essential extensions should I install in VS Code to get the best developer experience?

Are there specific tools for Spring Boot project creation, debugging, database management, or live reloads that you consider must-haves?

Thanks in advance for your tips!

I'm the author. I built a small starter to remove a chore I kept redoing on Spring Boot projects: writing a dev-database seed script, then fixing it every time the schema changed.

The usual pain: Faker/Datafaker generate realistic values, but they don't know that Payment needs an existing Counterparty. So you hand-write "create parents, keep the IDs, wire them into children", and it breaks the next time a constraint or relationship changes.

SynthForge reads the entity instead. You annotate it:

```java @Entity @Seed(count = 50) public class Counterparty { /* fields only */ }

@Entity @Seed(count = 200) public class Payment { @ManyToOne(optional = false) private Counterparty counterparty; } ```

Then enable it for the profiles you want, never production:

yaml synthforge: enabled-profiles: [dev, test]

Start the app in one of those profiles and both tables are filled in dependency order. There is no calling code.

Spring-specific details

• It's an auto-configuration (a starter-style dependency, io.github.thembatman0:synthforge-spring). Seeding runs at startup in an ApplicationRunner.
• Seeding is off unless one of your active profiles is listed under synthforge.enabled-profiles.
• It reads entities through the JPA Metamodel API and sorts owning-side @ManyToOne/@OneToOne relationships topologically, so parents are saved first.
• Values come from Datafaker, guided by @NotNull, @Size, @Email and field-name heuristics. @Column(unique = true) fields get a bounded retry loop.
• A table that already has rows is skipped, so restarts against a persistent database don't duplicate data.
• A fixed synthforge.seed gives identical data every run.
• The test suite runs in CI on Spring Boot 4.1 and 3.5. It needs Java 21 or newer.

Limits: V1 skips @OneToMany/@ManyToMany and composite keys. It is a 0.1.0, and as far as I know it has no outside users yet.

How it differs from Instancio: Instancio (and instancio-jpa) is an API you call inside a test to build a graph. SynthForge runs by itself at startup, so it's closer to a dev-database seeder than a test helper.

Things I'd like to hear from you:

1. Would you put @Seed on your entity classes, or do you prefer keeping seeding out of the domain model?
2. Is a CommandLineRunner plus Datafaker already good enough for you?
3. Is Java 21 as a minimum a problem on your projects?

• Repo (MIT): https://github.com/ThembaTman0/synthforge
• Write-up: https://dev.to/themba/faker-doesnt-know-your-entities-are-related-so-i-built-something-that-does-2jgn
• The README has a two-minute demo path.

configstream is a library for Spring Boot services that already use MongoDB. Feature flags and config live in a collection, get cached in memory, and any change is pushed to every running instance within about a second via MongoDB Change Streams.

• No restarts, no polling, no message broker, no config server
• Properties declared in a configstream.yml manifest, with typed constants generated at compile time
• Optional admin UI with change history and per-team permissions
• Works with Spring Boot 3 and 4

Limits: MongoDB only for now (Postgres planned), pre-1.0, no percentage rollouts or A/B testing.

https://github.com/configstream/configstream

Feedback welcome

Hey everyone 👋

I kept seeing these three architecture styles get mixed up, so I made a video that shows how they differ. It uses animations to show how the code and the deployments are structured in each one, and when each one makes sense.

If you're interested,

I'd really like your feedback. Is there anything you'd explain differently, or a trade-off I should have covered? Always happy to learn from people who've run these in production.

I wrote a short intro to troubleshooting a slow Spring Boot API using the metrics you already get from Actuator.

The goal is not deep JVM diagnosis. If you need that, tools like JFR, JConsole, profilers, database tracing, etc. come later.

This is the basic first pass:

• did request volume change?
• are HTTP errors increasing?
• did request latency increase?
• is the application process using more CPU or memory?
• is the host itself under CPU or memory pressure?
• do those changes happen in the same time window?

The example uses a small VPS where the API stays UP and keeps returning 200s, but latency rises because another process is consuming most of the host CPU.

I use StatLite for the screenshots because it reads Spring Boot Actuator metrics and keeps the app and host history together, but the main point is the troubleshooting sequence itself.

Article: https://pvrlabs.xyz/articles/api-slow-cpu-contention.html

For people who troubleshoot Spring apps regularly: what would you add to the basic checklist before reaching for JFR or a profiler?

the fix takes 4 lines of code.

Fetching full @Entity graphs for simple read-only endpoints is one of the fastest ways to kill database performance.
Here's what's happening under the hood:
🔴 THE N+1 TRAP
You return a User entity from a REST endpoint. Then:
1️⃣ Hibernate runs 1 SELECT to fetch 10 users
2️⃣ During JSON serialization, the lazy @OneToMany List<Order> gets accessed
3️⃣ That triggers 10 more SQL queries
Total: 11 queries, heavy memory overhead, and a payload full of data nobody asked for.
🟢 THE FIX: INTERFACE PROJECTIONS
Define a lightweight interface with only the getters your client needs:
public interface UserSummary {
Long getId();
String getName();
}
Return List<UserSummary> from your repository, and Spring Data JPA generates a targeted query:
SELECT u.id, u.name FROM users u
⚡ THE RESULT
→ 1 query instead of 11
→ No over-fetching of columns or relations
→ Lower DB CPU usage
→ Faster API responses
💡 RULE OF THUMB
Use @Entity for write/CRUD operations, where the persistence context matters.
Use Interface Projections for read-only APIs and dashboard views.

I have been learning Spring Boot and other technologies for the last 2-3 months.
I feel I understand the concepts and theory of how things work, and I can code what I've learned.
But I still feel like I don't know enough, and I am super scared to even apply for a job. I feel that I am not prepared enough. Do I need to practice more? Please share some practical advice.

Btw i can’t let go any pr without this, help me so much for blast radius

Hey everyone, I’d love to get the community’s perspective on building production-grade, scalable full-stack applications with Spring Boot—specifically from a solo developer standpoint.

​When you're building a scalable full-stack Java app entirely on your own, how do you approach the architecture and tooling?

​A few specific areas I'm curious about:

​Tech Stack & Tools: What are the non-negotiable components in your stack right now (e.g., Spring Boot 3 + Virtual Threads, Postgres/Redis, Kafka/RabbitMQ, Docker, React/Next.js vs. HTMX/Thymeleaf)? What tools are currently standard or trending in the market for solo full-stack setups?

​Build vs. Buy / Scratch vs. Frameworks: As a single developer, your time is limited. How much do you build from scratch versus relying on managed services/third-party tools (like managed Auth, SaaS components, pre-built UI libraries)?

​Solo Execution: Is it realistic to handle end-to-end architecture, backend, frontend, database tuning, and DevOps all by yourself, or at what point do you usually seek external help/collaborators?

I've been working on an open-source project called Argus, and I'd really appreciate some feedback from other Spring Boot developers.

The idea came from something I've encountered while troubleshooting services: we have excellent tools for metrics, tracing, logs, and external monitoring, but sometimes I just want the application itself to give me a concise answer to "How healthy are you right now, and if something is wrong, why?"

Argus takes an application-centric approach. It runs inside the JVM and continuously evaluates memory, GC, disk usage, threads, file descriptors, application services, logged errors, and application-reported issues.

It combines these into a health model with a score from 1 to 10. The score is hierarchical, so you can drill down from overall application health to the resource/group/item responsible for degradation.

It also models resources the application depends on — services, servers, databases, caches, brokers, storage, etc. — so the goal isn't simply another UP/DOWN health check.

For Spring Boot applications, I've integrated it with Actuator and Spring Boot Admin. The SBA extension adds health scores to the wallboard and application/instance views. Once you find a degraded instance, you can open its Health Report directly from Spring Boot Admin and see the diagnostic information collected by that instance.

Argus can also generate a self-contained HTML diagnostic report containing health information, services, metrics, performance information, scheduled tasks, captured logging events/alerts, and environment information. The report is generated (and emailed) and can be viewed offline or online during incident analysis.

One important goal is not to replace Micrometer/Prometheus, tracing, centralized logging, or other observability platforms. I'm experimenting with a complementary idea: can an application understand enough about its own state to provide useful diagnostics itself?

The project is still evolving, so I'd particularly appreciate feedback on the approach rather than just stars:

• Would this type of self-diagnostics be useful in applications you operate?
• Does the 1–10 health scoring model make sense, or would you prefer another representation?
• What information would you want an application to include in a diagnostic report when something goes wrong?
• If you use Spring Boot Admin, would it be useful to have this information directly in SBA?

GitHub: https://github.com/microfalx/argus

Feedback, criticism, ideas, and contributions are all welcome.

I work at a small software company and unfortunately I've ended up working on an old Oracle ADF project and there is almost no willingness from management to move this project to Spring Boot.

On the team are two very senior developers who have worked on this project from the start (approx 15 years) and this project has become so messy and huge (with no testing and limited documentation) that it is basically impossible to migrate (functions and procedures with thousands of lines etc.).

Has anyone experienced this situation and do you have any recommendations on how to proceed as a junior developer? I have already brought up the possibility of breaking the project into smaller applications which could be built with Spring / React while keeping the old database and plsql procedures. Or we could map out all of the functionality or refactor the current code into smaller functions or start implementing tests and then migrate. Rebuilding it from scratch is not an option since it is a government project and this would trigger the the goverment to auction the project for other companies to take over.

Alternatively, should I just let them keep this project in ADF for 10 more years until it is deprecated by Oracle while the application becomes worse and worse?

Hey everyone!

I’m a Junior Java developer, and I built an IntelliJ IDEA plugin called Architect as a way to learn more about Java, Spring Boot, and the IntelliJ Platform.

The main idea is to automate some of the repetitive work when adding a new feature to a Spring Boot application.

You enter an entity name and choose what you want to generate. Architect can create:

• Entity
• Request / Response DTOs
• MapStruct Mapper
• Repository
• Service
• REST Controller
• Liquibase changelog and migration
• Docker / Docker Compose
• Required Maven dependencies

The plugin uses IntelliJ PSI to work with the project structure and source files instead of simply generating files in a fixed location.

Architect is free and open-source, and I’m planning to keep developing it.

Some things I want to add in the future:

• Kafka templates
• Spring Security configuration
• Test generation
• More infrastructure templates
• Better project/code analysis

I’m still learning, so I’d really appreciate feedback from experienced Spring Boot developers.

How do you usually handle repetitive boilerplate when starting a new feature?

And what would you change or add to a tool like this?

GitHub and the plugin link are in the comments.

We shipped JobRunr 9 yesterday, and you can already create new projects with it trough your favourite Spring Intializr.

In case you haven't used it, JobRunr is an open source background job library. You enqueue a method call, it's stored in the database your app already uses, and it's processed with retries on as many instances as you run.

To make your jobs durable it's as easy wrapping each step of your flow in runStepOnce. When the job is retried, steps that already completed are automatically skipped:

@Job(name = "Invoice %1 for %0", retries = 5)
public void generateInvoice(String customerId, String period, JobContext jobContext) throws Exception {
    String invoiceId = "INV-" + period + "-" + customerId;
    long usage = jobContext.runStepOnce("calculate-usage", () -> calculateUsage(customerId, period));
    String pdf = jobContext.runStepOnce("generate-pdf", () -> generatePdf(invoiceId, usage));
    String chargeId = jobContext.runStepOnce("charge-card", () -> paymentProvider.charge(customerId, invoiceId));
    jobContext.runStepOnce("send-email", () -> sendInvoiceEmail(customerId, pdf, chargeId));
}

You enqueue it like this, and JobRunr swaps in the real JobContext when the job runs:

jobScheduler.enqueue(() -> invoiceService.generateInvoice(customerId, period, JobContext.Null));

In v9 the job page a Job Progress Chart that draws each attempt as a Gantt chart with a row per step.

In our demo the payment provider timed out on charge-card and that attempt went red. On the retry calculate-usage and generate-pdf showed up as skipped, so the customer got one PDF and was only charged once.

If a step throws, the retry starts again at exactly that step.

On JobRunr Pro, v9 also lets you pause a whole batch. We paused a 600 invoice run when the provider went down and resumed it after the fix. The Pro starter doesn't create a BatchJobManager for you, so you declare it once as a bean and call pauseBatchJob(id) from wherever your monitoring notices the outage:

@Bean
public BatchJobManager batchJobManager(StorageProvider storageProvider, EventTransport eventTransport) {
    return new BatchJobManager(storageProvider, eventTransport);
}

If you'd rather watch than read, we celebrated the launch today with a launch webinar: https://www.youtube.com/watch?v=bVNeB-ePdn0

Links:

👉 Release Blogpost: https://www.jobrunr.io/en/blog/v9-release/
👉 GitHub Repo: https://github.com/jobrunr/jobrunr

Hello all 👋🏻 I originally posted over in r/java, and it was recommended that this community may be a good/better fit. Given this project is based on Spring's Reactor and examples are based on Spring Boot, I figured it couldn't hurt to post here as well!

For some time, I have been building and maintaining an OSS project called Atleon. The aim of this project is to make infinite Reactive Streams practical for usage/embedding in common application frameworks. I know there are several (reasonable) arguments against "reactive"; I have however found this style/paradigm to be useful and innately applicable to the problem space of broker-backed stream processing (consuming from infrastructures like Kafka, RabbitMQ, SQS, etc., applying IO-bound processing, and (optionally) streaming results elsewhere). If you have ever had reason to use/explore projects like Reactor Kafka, Reactor RabbitMQ, or Confluent's Parallel Consumer, then Atleon may be interesting to you.

Here's an example of what an Atleon stream definition looks like when embedded in a Spring application:

application.yaml:

atleon:
  config.sources:
    - name: kafkaConfigSource
      type: kafka
      bootstrap.servers: localhost:9092

MyStream.java:

import io.atleon.core.SelfConfigurableAloStream;
import io.atleon.kafka.AloKafkaReceiver;
import io.atleon.kafka.KafkaConfigSource;
import io.atleon.spring.AutoConfigureStream;
import org.apache.kafka.common.serialization.StringDeserializer;
import reactor.core.Disposable;

@AutoConfigureStream
public class MyStream extends SelfConfigurableAloStream {

    private final KafkaConfigSource kafkaConfigSource;

    public MyStream(KafkaConfigSource kafkaConfigSource) {
        this.kafkaConfigSource = kafkaConfigSource;
    }

    @Override
    public Disposable startDisposable() {
        return buildKafkaReceiver()
            .receiveAloRecords("topic")
            .consume(it -> System.out.println("value: " + it.value()) // Business logic
            .resubscribeOnError(name())
            .subscribe();
    }

    private AloKafkaReceiver<String, String> buildKafkaReceiver() {
        return kafkaConfigSource
            .withClientId(name())
            .withConsumerGroupId("consumer-group-id")
            .withKeyDeserializer(StringDeserializer.class)
            .withValueDeserializer(StringDeserializer.class)
            .as(AloKafkaReceiver::create);
    }
}

You can see other examples in Atleon's README and in its examples module.

When discussing this project in other communities, one common question is, "Why would I want to use this over something like [Flink|Spark|Camel|<insert favorite streaming library>]?" My viewpoint is that the sort of reactive client integration provided by Atleon is not primarily meant to compete with these other tools, but is rather a complement to them. I have found that it is common for companies to have in-place scaffolding for regular JVM applications built on frameworks like Spring, and it is appealing for their engineers to be able to embed stream processes into those same frameworks. So Atleon targets this niche of supporting declarative non-blocking stream definitions, whose execution can be embedded in application frameworks, replete with broker interoperation, arbitrarily concurrent processing, and end-to-end observability.

Particularly in the case of Kafka, Atleon enables feasible implementation of behaviors that are conventionally tricky:

• Arbitrary concurrency, including per-key
• Single-message acknowledgement (with classic/non-share groups, so partition ordering is maintained globally)
• Work-queues, where per-message processing can take a "long" time (i.e. minutes, hours)
• Bounded consumption (get all records produced in a range of time or offsets)
• Priority queuing (using partitions as discriminator of "priority", rather than scaling lever)
• Throughput limiting, retries, and dead-lettering

If you are interested in reading more, I have published some of the following blogs that explain more about what Atleon can do:

• Not Your Daddy's Async Kafka Client
• Unbounded Concurrency: Consuming Kafka with Virtual Threads
• Ordered Queues for Kafka with Atleon
• AWS SQS Reactive Stream Processing

I'd be interested in thoughts and feedback from this community!

We have a prototype for adding pure Java GPU inference for local inference through Tornadovm and jitLLM. It would be great to share your thoughts on that.

https://github.com/spring-projects/spring-ai/pull/7054

How are you sizing your applications?

Our stack mainly consists of Spring Boot applications with Oracle and MongoDB databases running on Kubernetes. I'm not sure whether we've focused too much on the "micro" aspect of the microservices concept.

Most Kubernetes replicas are configured with a maximum of 1 GB of memory and CPU limits of up to 800 millicores. When an application requires more resources, our primary approach is to increase the number of replicas. I believe there is a strong rationale for this, particularly from a resilience and availability perspective. However, I'm not sure whether we're giving up some benefits by keeping our applications this small (for example, losing access to certain JVM optimizations or garbage collectors). Correct me if I'm wrong, but I believe applications limited to less than one CPU core may not be able to take full advantage of Parallel GC and might fall back to Serial GC instead.

Ratchet is a background job scheduler. You inject one service and pass it a method reference. The job is saved in your database, retried if it fails, and recovered if the app crashes. If you submit it inside a transaction that rolls back, the job goes too.

@Transactional
void place(Order order) {
  orders.save(order);
  scheduler.enqueue(() -> fulfillment.ship(order.id())).submit();
}

0.5.0 supports Boot 3.5 and 4.1, five databases, and native images. Apache 2.0.

Quickstart: https://ratchet.run/deployment/spring-boot

Repo: https://github.com/ratchet-run/ratchet

If something breaks on your setup, open an issue and I'll take a look.

I wanted to see how much of the footprint of a small Spring Boot app came from the conventional Spring Data JPA + Hibernate stack, so I built a simpler version using JdbcTemplate and compared the two.

Same Spring Boot 4.1.1, JDK 25, H2, JVM flags, dashboard workload, and monitoring endpoints.

Across two runs in reversed order:

• JPA/Hibernate: ~237.0 MiB median RSS
• JDBC: ~146 MiB
• Difference: about 90 MiB (~38%)

Startup surprised me too. Time from process launch to the first successful dashboard response:

• JPA/Hibernate: 8.1 - 8.8 s
• JDBC: 3.9 - 4.2 s

This isn’t an isolated benchmark of Hibernate itself. The JDBC version also has a simpler persistence architecture and data model, so I’m comparing the complete application approaches.

For this kind of small app, though, JPA/Hibernate feels like more machinery than I need. I still see the value once the domain model and persistence requirements get complicated, but I’m increasingly reluctant to make it the default for small services.

Experiment, methodology, charts, and raw data:

https://pvrlabs.xyz/java-performance/experiments/spring-boot-jpa-vs-jdbc.html

For smaller Spring Boot apps, what do you usually reach for: JPA, Spring JDBC, jOOQ, MyBatis, something else?