Version 1.0.2 — Known Issues with Default Handling

Recommendation

It is not recommended to use version 1.0.2.
This release contains bugs in how endpoint metadata handles default values, leading to unexpected behavior. Please use version 1.0.1 or wait for the next release with proper fixes.

---

What Was Intended

Version 1.0.2 was designed to improve the developer experience by allowing class-level metadata (via the @Chaza annotation) to serve as defaults for endpoints.

For example, if a value like contentType or roles was not explicitly provided in an @EndPoint annotation, the system would automatically fall back to using the value from the surrounding @Chaza class annotation.

The idea was to:

• Reduce repetition across multiple endpoints.
• Make code more concise and DRY.
• Allow developers to define global API behavior in one place.

---

What Went Wrong — The Bug

Many fields in @EndPoint were given default values such as:

String contentType() default "text/plain";
String[] roles() default {"any"};

Default Value Bug in Version 1.0.2

Why Fallbacks Didn't Work

Because of this:

• Java treated these fields as already set, even when left empty.
• ChazaAPI could not distinguish between “unset” and “explicitly empty” values.
• As a result, the fallback to class-level @Chaza defaults was skipped.

Example

@Chaza(contentType = "application/json" , roles = {"admin","user"})
public class UserController {

    @EndPoint(
        method = Method.GET,
        url = "/users"
        // Expected to use contentType = "application/json" from @Chaza but will use
        // text/plain because that was the default
        // roles = {"any"} despite @Chaza specifying because the roles were already predefined
    )
    public void getUsers() {}
}