Re: [cdi-dev] About parsing beans.xml files in Lite

[Edward Moore <edward.moore39@xxxxxxxxx>]

Hello

On Tuesday, 26 January 2021, 13:57:43 GMT, Ladislav Thon <lthon@xxxxxxxxxx> wrote:

> Given that we've now repeated many times that what we're trying to build is a subset of CDI, I have to assume that you're talking exclusively about extensions. So here's a thing: portable extensions can't be made to work under the set of constraints I've outlined previously

I don't understand. Why can the new extension API not be a subset of the existing API? Why can it not use the same names?

A quick glance

Your API

Discovery

Existing API

BeforeBeanDiscovery

Purpose

Add classes

Your API

Enhancement

Existing API

ProcessBean

Purpose

Add and remove annotations

Your API

Synthesis

Existing API

AfterBeanDiscovery

Purpose

Adding synthetic beans

Your API

Validation

Existing API

AfterDeploymentValidation

Purpose

Add error

If we look at the names, we see "Synthesis" vs "AfterBeanDiscovery". Why are those names so different? Why not use the same name? Make it easier for your users, and don't have us remember multiple names for the same thing.

If we look at the interfaces, let's look at:

public interface AfterDeploymentValidation {

    /**
     * Registers a deployment problem with the container, causing the container to abort deployment after all observers have
     * been notified.
     *
     * @param t The deployment problem as a {@link java.lang.Throwable}
     * @throws IllegalStateException if called outside of the observer method invocation
     */
    public void addDeploymentProblem(Throwable t);

}

Why can't you use this for the build-time extension?