1 Reply Latest reply on Apr 26, 2019 2:56 AM by manovotn

Bean discovery in test and wildfly (production)

remikwro Apr 25, 2019 9:52 AM

We are currently facing some issues regarding the discovery of beans.

We have two environments (SE and EE with Wildfly) and in the SE environment we have a few beans that we want to turn off (we dont need them for running tests).

Those beans are discovered in a subproject that has a beans.xml (WELD gets started in a different subproject which is called standalone).

If we turn them off in beans xml in that specific subproject, it works fine for tests BUT this also turns them off in EE (wildfly).

We tried to turn them off in that standalone project but standalone has no dependency to those other subprojects that get discovered when starting the root project that has dependencies to standalone and those subprojects.

How are we supposed to control how bean discovery should work in that root project so that it works differently for test/production?

Additional infos about standalone:

In standalone we have a few "dummy" beans like usertransaction etc. which we add dynamically in an extension (which we use when we initialize weld). We want to keep the weld initializing/start there for that reason.

1. Re: Bean discovery in test and wildfly (production)

manovotn Apr 26, 2019 2:56 AM (in response to remikwro)

Hello,

so if I understand it correctly, you are running only tests in SE, so you must be using Weld SE for that. I'm not sure I can see the structure you have in place (the "subproject"), but first thing coming to mind is using a synthetic archive for testing - e.g. disabling discovery for Weld SE and telling Weld what exactly you want to have in the archive. Note that this disregards beans.xml you have there and based on your structure this may or may nor be a problem to put together; worth a shot though.
As for how to do it, take a look here, namely the snippet which does disableDiscovery().

If you were running tests in EE, then Arquillian is the answer as you can, via Shrinkwrap, decide what will be in the deployed archive hence leave out any unwanted bits.

Also, what is the reason to avoid having those beans in place? From what you say it doesn't like they are alternatives you want to replace? Weld is lazy and won't actually create those beans unless you try to use them in your tests. Obviously, it will still discover them and validate them, but that's about all that happens.
Actions