Question regarding SE and extensions when an extension is both supplied and discovered

[ljnelson]

Sorry, it's me again. I guess I'm the only one using the discussions area for some reason. Tell me if I should go somewhere else.

When a portable extension class is discoverable, and an instance of that class is passed to CDI SE's addExtensions(Extension...), which instance must receive lifecycle events?

I'm guessing the answer in CDI is "undefined" (as usual). But maybe it's a Weld thing, so I thought I'd ask here first.

[manovotn]

Sorry, it's me again. I guess I'm the only one using the discussions area for some reason. Tell me if I should go somewhere else.

No problem, you are in the right place :)

When a portable extension class is discoverable, and an instance of that class is passed to CDI SE's addExtensions(Extension...), which instance must receive lifecycle events?

I'm guessing the answer in CDI is "undefined" (as usual). But maybe it's a Weld thing, so I thought I'd ask here first.

No, CDI doesn't specify this. I think this was added into SE after EE model where in some cases it was important for an integrator to initialize an extension into certain state before handing it over to CDI. That said, it wasn't considered what should happen if you have both (and I guess each server deals with it differently).
@tk1475 is right in his analysis of current Weld behavior.

We could try and define some rules but that's assuming we can do some detection which may or may not work. You can do some instanceof checks but there isn't much you can do if you attempted to register several instances of class A implement Extension. There, you are down to object identity to even tell them apart.
@ljnelson what was your expectation in this case? Override? Delivery to all?

[ljnelson]

I guess naïvely "override": when discovery is in effect, there's only one instance of an extension, and the container is obligated to create a singleton bean for that extension. It seems like if I then pass in an explicitly initialized instance, then the discovery one should be ignored (with logging or a warning or something) since I basically said "here, use this instance". But I haven't thought deeply about this.

[manovotn]

I wouldn't be opposed to it; care to send a PR?

[ljnelson]

In my copious free time ;-) but sure. This one will require some thinking. Maybe Weld should make the discovered extension a @Reserve (effectively). Then the supplied extension would receive lifecycle events, but both extension instances would continue to exist as they do today, but at least there would be some meaning to this.

[manovotn]

Extensions have somewhat special handling - they are injectable, eventually, but they also have to exist long before any bean does. Or even any annotated type for that matter. Reserves are therefore out of question.
You need to resolve the ambiguity before you even start the container - I'd place it in Weld SE class directly. That way, it wouldn't interfere with whatever EE servers might have been doing with this kind of registration either.