Accessing enum via Jakarta Expression Languauge in Pages

by

Summary

A developer encountered a jakarta.el.PropertyNotFoundException: Unknown identifier [suit] when attempting to access a Java enum directly via Jakarta Expression Language (EL) in a JSP page. The developer annotated the enum with @Named and @ApplicationScoped, expecting it to be automatically resolvable as a bean named “suit”. The core issue stems from a misunderstanding of how the EL name resolver works: while static fields of classes can be accessed via EL, enums annotated with CDI stereotypes are not automatically registered as named beans in the standard way required for direct EL resolution.

Root Cause

The root cause is the mismatch between the developer’s expectation of CDI bean discovery and the actual behavior of the Jakarta EE container regarding enums.

  • Invalid Bean Definition: An enum cannot be a CDI bean in the standard sense. While you can add annotations to an enum, it does not make the enum type itself resolvable by name in the EL context. CDI manages instances, but an enum is a static type definition.
  • Missing Explicit Registration: The EL resolver does not automatically scan the classpath for annotated enums and register them under their class names.
  • Scope Confusion: @ApplicationScoped implies the container manages a lifecycle, which is conceptually incompatible with a Java enum (which is a static singleton defined by the JVM). The container ignores the annotation for the purpose of EL name resolution.

Why This Happens in Real Systems

This specific failure pattern occurs frequently due to the complexity of modern Jakarta EE specifications:

  • Ambiguous Specifications: The documentation for Expression Language often describes accessing static fields (e.g., ${Math.PI}) or accessing named beans (e.g., ${userBean.name}). It rarely explicitly details that annotated enums are a “non-feature” for direct EL resolution.
  • IDE Assumptions: Modern IDEs suggest adding @Named to any class to make it accessible in EL, leading developers to apply this pattern blindly to enums without verifying if the underlying container supports it.
  • Legacy Migration: Developers moving from older frameworks or different languages might assume that if a class is annotated as a “Component” or “Bean,” it is globally addressable by name.

Real-World Impact

  • Runtime Blocking: The application fails at runtime with a 500 error, stopping page rendering completely because of errorOnELNotFound="true".
  • Wasted Debugging Time: Developers spend time verifying CDI scopes, beans.xml configuration, and annotation processors, none of which will fix the issue because the problem is structural.
  • Workaround Bloat: To fix it, developers often create a wrapper class (e.g., SuitWrapper) or a utility static method, adding unnecessary boilerplate code to the project.

Example or Code

To reproduce the issue, the developer likely attempted this pattern:

import jakarta.enterprise.context.ApplicationScoped;
import jakarta.inject.Named;

@Named
@ApplicationScoped
public enum Suit {hearts, spades, diamonds, clubs}

And tried to access it in JSP/EL:

${suit.hearts}

This results in PropertyNotFoundException.

How Senior Engineers Fix It

Senior engineers avoid trying to force the enum to be a bean. Instead, they bridge the gap between the static nature of the enum and the dynamic nature of EL.

Option 1: The Static Accessor (Recommended)
Create a simple static utility class that exposes the enum values.

public class SuitUtil {
    public static Suit getHearts() { return Suit.hearts; }
    public static Suit getSpades() { return Suit.spades; }
    // ... etc
}

EL usage: ${SuitUtil.hearts} (This works because EL resolves classes for static access).

Option 2: The Wrapper Bean
Define a specific bean that holds the enum constants as properties.

@Named
@ApplicationScoped
public class SuitProvider {
    public Suit getHearts() { return Suit.hearts; }
}

EL usage: ${suitProvider.hearts}.

Option 3: Instantiate and Pass (Session/Request Scoped)
If the enum needs to be compared against a user’s selection, do not try to make the definition accessible. Instead, ensure the instance is in the scope.

// In the backing controller
public String getPage() {
    // Ensure 'myCurrentSuit' is in request/session scope
    request.setAttribute("mySuit", Suit.hearts); 
    return "page";
}

EL usage: ${mySuit == 'hearts'} (Enum toString is usually the name, or you compare directly).

Why Juniors Miss It

  • “Convention over Configuration” Trap: Juniors are taught that annotating a class with @Named makes it available in EL. They assume this applies to all class types.
  • Lack of Specification Knowledge: They don’t realize that Java Enums are implicitly static singletons and do not follow the JavaBean conventions (getters/setters) that many EL resolvers expect for properties.
  • Over-reliance on Annotations: They believe annotations are “magic” that alters the behavior of the JVM/Compiler at runtime, rather than just metadata that requires a specific processor (which isn’t looking for enums).