23 define and create filter interface

[eraiicphu]

• Added HttpRequest class, a data object that represents an HTTP request.
• Added a interface for Filters and FilterChain
• Created FilterChainImpl, that is the defaultclass for FilterChain

Summary by CodeRabbit

• New Features
  • Added a request filter framework with lifecycle hooks (init, apply, destroy) for modular request processing.
  • Added a chainable filter executor to run configured filters sequentially and advance processing.
  • Introduced an immutable HTTP request model exposing method, path, version, headers and body for safe access.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

Adds a filter-chain subsystem: Filter and FilterChain interfaces, a FilterChainImpl that iterates and invokes filters (advances index, delegates to each filter and uses this for chaining; final execution left TODO), and an immutable HttpRequest model with method, path, version, headers, and body plus accessors.

Changes

Cohort / File(s)	Summary
Filter interface src/main/java/org/example/filter/Filter.java	Adds Filter interface with lifecycle methods init() and destroy() and processing method doFilter(HttpRequest request, HttpResponseBuilder response, FilterChain chain).
FilterChain API src/main/java/org/example/filter/FilterChain.java	Adds FilterChain interface with void doFilter(HttpRequest request, HttpResponseBuilder response).
Filter chain implementation src/main/java/org/example/filter/FilterChainImpl.java	Adds FilterChainImpl implementing FilterChain, holding List<Filter> and an index; doFilter advances through filters, invokes each filter's doFilter(request, response, this), and leaves final request execution as TODO.
HTTP request model src/main/java/org/example/httpparser/HttpRequest.java	Adds immutable-style HttpRequest class with final fields method, path, version, headers (defensive copy), and body, plus public getters; no mutators or attributes map added.

Sequence Diagram

sequenceDiagram
    participant Client
    participant Chain as FilterChainImpl
    participant FilterA as Filter
    participant FilterB as Filter
    participant Endpoint

    Client->>Chain: doFilter(request, response)
    Chain->>FilterA: FilterA.doFilter(request, response, this)
    FilterA->>Chain: chain.doFilter(request, response)
    Chain->>FilterB: FilterB.doFilter(request, response, this)
    FilterB->>Chain: chain.doFilter(request, response)
    Chain->>Endpoint: execute final request (TODO)
    Endpoint-->>Client: response

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐇 I hop through code with playful cheer,
Filters line up, the path is clear,
init, pass onward, then destroy with glee,
Requests tucked safe in headers and key —
Hooray, the chain will set them free!

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'define and create filter interface' accurately summarizes the main objective of the PR, which is to define the Filter and FilterChain interfaces and create their implementation (FilterChainImpl), along with the supporting HttpRequest class needed for the filter chain to function.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch 23-define-and-create-filter-interface

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In `@src/main/java/org/example/filter/FilterChain.java`:
- Line 5: The files FilterChain, Filter, and FilterChainImpl incorrectly import
java.net.http.HttpRequest; replace that import with the project's custom request
class org.example.httpparser.HttpRequest so the interfaces and implementations
(e.g., class FilterChain, interface Filter, class FilterChainImpl) use the
correct type and are compatible across the PR.

In `@src/main/java/org/example/filter/FilterChainImpl.java`:
- Around line 5-6: In FilterChainImpl remove the unused import
java.io.IOException and replace the incorrect java.net.http.HttpRequest import
with the servlet request type used by the project (e.g.,
javax.servlet.http.HttpServletRequest) so the class compiles; update any
references inside FilterChainImpl to use HttpServletRequest (matching the
import) and mirror the same fix applied in FilterChain.java.

🧹 Nitpick comments (3)

src/main/java/org/example/filter/FilterChain.java (1)

7-9: FilterChain.doFilter should not take a FilterChain parameter.

In the standard Servlet Filter pattern, FilterChain.doFilter(request, response) does not accept a chain argument — the chain is this. The chain parameter is redundant here and also inconsistent with how FilterChainImpl.doFilter actually works (it ignores the chain argument and uses this internally on Line 28 of FilterChainImpl.java).

♻️ Simplify the signature

 public interface FilterChain {
-    void doFilter(HttpRequest request, HttpResponseBuilder response, FilterChain chain);
+    void doFilter(HttpRequest request, HttpResponseBuilder response);
 }

Then update Filter.doFilter similarly — filters call chain.doFilter(request, response) to continue the chain.

src/main/java/org/example/filter/FilterChainImpl.java (2)

20-22: Consider making a defensive copy of the filters list.

The constructor stores the list by reference. If the caller mutates the list after constructing the chain, it will corrupt the chain's iteration. Use List.copyOf(filters) for safety, consistent with the defensive-copy approach used in HttpRequest for headers.

♻️ Proposed fix

 public FilterChainImpl(List<Filter> filters) {
-    this.filters = filters;
+    this.filters = List.copyOf(filters);
 }

---

24-32: The chain parameter is ignored — this is used instead.

Line 28 passes this rather than the chain argument, confirming the parameter is redundant (as noted in the FilterChain interface comment). Also, the TODO on Line 30 should be tracked — when the chain is exhausted, this is where the actual request handler (servlet/endpoint) should be invoked.

Would you like me to open an issue to track the TODO for invoking the terminal request handler when all filters have been processed?

[gvaguirres]

Jag har märkt att det finns dubbla implementeringar av FilterChain och HttpRequest både här och i PR "Url redirect filter". Jag undrar vilken av dessa implementeringar som passar bäst för vårt projekt?

Om vi inkluderar båda kommer vi att få namnkonflikter och redundant kod i projektet. Det vore bra om vi kunde komma överens om en gemensam struktur innan vi mergar.

[AntonAhlqvist]

Du skulle kunna lägga till minimala setAttribute/getAttribute i HttpRequest för att ge filter möjlighet att spara metadata på requesten på ett enkelt och generellt sätt.

Till exempel genom att lägga till fältet:

private final Map<String, Object> attributes = new HashMap<>();

tillsammans med metoderna:

setAttribute(String key, Object value)

och:

getAttribute(String key).

[eraiicphu]

@AntonAhlqvist Inte alls en dum ide, den kom med i senaste push nu.
men då blir det väl en grej som måste tänkas på när vi skriver filters senare skede.
att funktionen finns. men också att om första filtret lägger en user och kedjas till en annat filter som också lägger in en user så skrivs den över utav sista tilldelningen.

Krävs att vi behöver veta vilken ordning filtren kommer att gå, och vilka attribut som kommer skrivas i tidigare filter.

[AntonAhlqvist]

@gvaguirres, jag missade din kommentar igår när jag skrev. Ledsen för det!

Har du några tankar kring arkitekturen när det kommer till HttpRequest? Som Eric nämnde finns det ju en risk för att filter skriver över varandras data om vi använder setAttribute/getAttribute. Om vi går den vägen krävs det nog att vi är rätt noga med hur vi namnger och hanterar den information som olika filter lägger till.

[viktorlindell12]

Grymt jobbat – tydlig HttpRequest-modell och bra att headers görs immutable med Map.copyOf.

En liten tanke: HTTP-headers är case-insensitive, så det kan vara värt att normalisera header-namn (t.ex. lowercase) eller ha en helper getHeader(name) som gör case-insensitive lookup. I övrigt ser det bra ut.

[AntonAhlqvist]

@eraiicphu

Under föreläsningen kom vi fram till att det är bäst att du återställer koden till hur den såg ut innan mitt förslag (det kan implementeras separat), så att pull-requesten kan färdigställas så snart som möjligt.

[AntonAhlqvist]

Toppen Eric!

Det var inte meningen att röra till allt, men nu ser det bra ut igen!

[Ericthilen]

ser bra ut!

[AnnaZiafar]

Ser bra ut, tycker att det är redo att mergeas