----- Original Message ----- https://gerrit.ovirt.org/#/c/52737/

----- Original Message ----- I may not understand your comment right, so I do apologize if i'm saying something nonsensical. Having parameterized constructors is OK, and their benefits are well known. However having CDI and parameterized constructors is somewhat contradictory — if it does something, then it's problems. Another side effect of this removal is also removal of some of reflection code, which is also good. postConstruct generally is preserved even without parameterized constructors. It's not too common in our code (if I'm not mistaken) to touch parameters/context in postconstruct, which is only true reason, why we *need* parameterized constructors. Even then, it's only wrong — these manipulations should not be done in postconstruct methods, but we can still workaround it, since, as we're calling injection manually, we can create bean, setup it, and then call injection. It's not good, sure, but it's better to have few bad places, that all places bad. I did simplest implementation for code review. It's not problematic to implement setup method so it can be called only once, thus modification of parameters / context are not possible just like with constructors. I don't understand this sentence. If you're talking about final fields immutability, then it's valid only for queryType. Other 3 fields (parameters, returnValue, engineContext) are mutable, so even if pointer remains unchanged, queries may fiddle with its content as they wish. If that was your point, there's actually no difference (I believe) in these 2 approaches. yes, it can be solved by requiring *one* full constructor with all required parameters through whole hierarchy tree. That way reflection cannot fail. It'd be smaller change, but as I said, getting rid of those constructors, we can probably get rid of all reflection (not in my patch) and probably also of special CDI treatment.