No, the exclusions are done on a per-archive basis, same as you would enable alternatives/interceptors via beans.xml. And in SE you either have discovery and beans.xml where you can specify it, or you use synthetic bean archive where you have full control over what gets inside, therefore you don't really need filters.
Well, not really. I do
def seContainer = SeContainerInitializer.newInstance()
.addProperty('javax.enterprise.inject.scan.implicit', TRUE)
.initialize()
and due to the classes and resources being in different directories on the class path, beans.xml would only be an option if I manipulate the runtime environment for the tests, so that classes and resources are in the same directory, or at least the beans.xml in the classes directory.
> Why "plus some suffix"?
Habit I guess... just so that you don't collide with some default, even though that's extremely unlikely. The random you posted is fine, you could also go with some common suffix for all classes you register such as clazz.getName() + " _manuallyRegistered". Anything, really.
Ok, thanks.
> That was more a sad gibe, that addAnnotatedType(AnnotatedType<?>, String) should better also return an AnnotatedTypeConfigurator
There are use cases where registering whole AnnotatedType is preferable to just using configurator. It is actually more powerful, but far more complex.
If you have an AnnotatedType anyway and just want to modify some details like adding or removing annotations. Of course one can simply use the addAnnotatedType(Class<?>, String) to get the configurator, but why not simply also return a configurator there to be able to manipulate the result? Anyway, that was just a side-note, I'm fine with using the Class version.
> From what I read there, the @Vetoed beans should also trigger a ProcessAnnotatedType event and I could remove the @Vetoed annotation there.
What Martin said is right, with @Vetoed you'd need to register the AT manually through BeforeBeanDiscovery.addAnnotatedType().
Yep, 11.5.6 that Martin quoted makes it clear. But then imho 12.4.1 that I quoted needs to mention @Vetoed too, as it states this:
First the container must discover types. The container discovers:
- each Java class, interface (excluding the special kind of interface declaration annotation type) or enum deployed in an explicit bean archive, and
- each Java class with a bean defining annotation in an implicit bean archive.
that is not excluded from discovery by an exclude filter as defined in Exclude filters.
Then, for every type discovered the container must create an AnnotatedType representing the type and fire an event of type ProcessAnnotatedType, as defined in ProcessAnnotatedType event.
Which made me think it should be fired even with @Vetoed.
So, as configuring the exclusion is not possible (except by manipulating the runtime environment to be able to use beans.xml), I see two options left, which would you say is better / preferable / has an advantage over the other? 1. Having @Alternative on the beans in question and then using
ProcessAnnotatedType#configureAnnotatedType().remove { it.annotationType() == Alternative }
for the beans to be used and
ProcessAnnotatedType#veto()
for the others or 2. Having @Vetoed on the beans in question and then using
BeforeBeanDiscovery#addAnnotatedType(clazz, "$clazz.name ${randomUUID()}").remove { it.annotationType() == Vetoed }
for the beans to be used |