Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdi-dev] CDI Lite compatible extension lead

Hi,

On 30. 09. 20 11:42, Emily Jiang wrote:
LT, thanks for your initial effort to get the ball rolling!
However, I am with Laird on clearly defining the user cases first so that the rest community can understand what the PR is trying to fix and then we can review and contribute towards the proposal (api, spec and tck).

I have a hard time understanding the desire to discuss use cases. Clearly the idea is to replace CDI extensions with a mechanism that is similarly powerful, caters to similar use cases, but removes an important architectural constraint (the need for everything to run in a single JVM).

As a developer, I want to use the CDI extension to:

  • Providing its own beans, interceptors and decorators to the container

The `@Discovery` phase has a method to add arbitrary classes to the "application". If such class doesn't have a bean defining annotation etc., you can add those annotation in the `@Enhancement` phase.

  • Injecting dependencies into its own objects using the dependency injection service

Sorry, I'm not sure what this means.

Is this about extension-contributed classes being treated as application classes, i.e. can have dependencies injected and themselves being injected, can declare observers, etc. etc.? If so, then sure, I'd say that's a given.

Or is this about being able to access the extension instance at application runtime? That would be a no-no I'm afraid. The instance is potentially long gone when the application starts. The class is potentially a different class (loaded by a different classloader in a different JVM).

  • Providing a context implementation for a custom scope

The `@Discovery` phase has a method to register custom context class. If the class doesn't have all the necessary metadata (such as the scope annotation), the API also has methods to set those.

  • Augmenting or overriding the annotation-based metadata with metadata from some other source

The `@Enhancement` phase is all about this.

There's also an API to add synthetic beans and observers (`@Synthesis`), and an API for validating the application and preventing successful build/deployment (`@Validation`). To sum up, the most important use cases for CDI extensions, as far as I can tell, are covered.

LT, can you double check whether this is the use case your PR is for? It will be very appreciated if you can put some code snippets to demonstrate how to achieve some of the use cases.

OK, let me try.

Registering a custom context:

public class MyContext implements AlterableContext { ... }

public class MyExtension {
    @Discovery
    public void customContext(Contexts contexts) {
        contexts.add().implementation(MyContext.class);
    }
}

Contributing a bean to the application:

@ApplicationScoped
public class MyBean { ... }

public class MyExtension {
    @Discovery
    public void customBean(AppArchiveBuilder app) {
        app.add(MyBean.class);
    }
}

Contributing a non-bean class to the application and making it a bean:

public class MyBean { ... }

public class MyExtension {
    @Discovery
    public void customClass(AppArchiveBuilder app) {
        app.add(MyBean.class);
    }

    @Enhancement
    public void makeItABean(ClassConfig<MyBean> bean) {
        bean.addAnnotation(ApplicationScoped.class);
    }
}

Vetoing a bean:

public class MyExtension {
    @Enhancement
    public void vetoABean(ClassConfig<SomeBean> bean) {
        bean.addAnnotation(Vetoed.class);
    }
}

Another example of annotation transformation is in the blog: http://www.cdi-spec.org/news/2020/09/15/CDI_Lite_extension/#a-class-that-uses-the-service

Makes sense? I know these are toy examples, but should give you an idea.

LT


If you can't deal with some of the use cases listed above, we can discuss here on whether we should reduce the scope or we can suggest some alternative solutions.

Thanks,
Emily


On Wed, Sep 30, 2020 at 9:41 AM Ladislav Thon <lthon@xxxxxxxxxx> wrote:
On 29. 09. 20 22:06, Jason Greene wrote:
On Sep 29, 2020, at 1:54 PM, Jason Greene <jason.greene@xxxxxxxxxx> wrote:
On Sep 29, 2020, at 1:32 PM, Laird Nelson <ljnelson@xxxxxxxxx> wrote:

On Tue, Sep 29, 2020 at 11:03 AM Jason Greene <jason.greene@xxxxxxxxxx> wrote:
Did you see Antoine’s blog in March?: 

Yes.  With (truly!!) all respect to Antoine, it's a bit all over the place and not a list of use cases or goals.

Can we just put down here, in simple bullet point formats, what at least the goals of this effort are?

I don't mean to suggest this is a trivial exercise, because it is not, and Emily certainly tried to get it rolling before (mostly unsuccessfully) with issue #425 (https://github.com/eclipse-ee4j/cdi/issues/425; and I applaud her attempt to start with the use cases).  But let's try again, here, publicly, on this list.

For the record, I'm definitely aware of {handwave} build time {handwave} no reflection {handwave} but I'm quite sure we can do better than that as a group.  Here is an incomplete sketch of one example of the sort of thing I had in mind.

Meta-goal: disrupt the specification as little as humanly possible (true of all specifications everywhere that are this old)
Goal: permit a CDI SeContainer to run a precomputed set of beans without having to run portable extensions
Why: certain products create their beans at build time/ahead of time: we want them to be part of the CDI fold as well
Hindrance: the SeContainerInitializer/portable extension APIs, even with something like SeContainerInitializer.disableDiscovery().addExtension(new Extension() { /* add beans here however they are generated/created */ }) is insufficient because of X, Y and Z
Hindrance: all (not just some) portable extensions must be available at runtime via BeanManager#getExtension()

…etc. and so on.  I can see the germs of something like this lurking in your posts and others' and in Antoine's blog article and elsewhere but I think it is necessary that we have small, traceable, actionable goals spelled out here before we try to solve them.

So I think we have explained the why quite a bit, and importantly we are talking about fundamental compatibility differences (two-phase multi-VM execution vs one phase), so you are already at the point of having to start anew. It’s not something that a simple API tweak here and there is going to solve.

Totally agree. I'd highlight what you put into parens :-) I have never considered it a use case, or anything worth extra mentioning, which in hindsight is an obivous mistake, so let me try to phrase it concretely.

Goal: modify the specification and the APIs to no longer assume that everything happens in a single JVM. It should be possible for a big part of the "application initialization lifecycle", including extensions, to run in another JVM, to "pre-wire" the application statically and enable significant performance gains during actual application startup.

(I understand this might not necessarily be a SMART goal. Sorry about that, I'm a simple man and prefer debating concrete ideas rather than abstract methodologies.)

Just a small clarification that I am specifically referring to portable extensions (#434) and the proposal (#451) which is the subject of this thread. This is the area that requires a reboot, to cover the same extension author use cases. 

The other areas of CDI are less of a problem, each of those items will have their own issue against them (which might involve small spec wording changes).  Some of them might be future decision points (should lite include X yes/no?) However, the hardest part of a potential CDI-Lite is solving the portable extension problem, so IMO it makes sense to tackle this area first. FWIW we new this would tough, so we first proposed just leaving this aspect to venders, but a number of commenters really wanted to see work on a new SPI. So here we go :)

Yes!

LT


-Jason


_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev


--
Thanks
Emily


_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev

Back to the top