Thats at least the current situation and we should really talk about it if we should move our artifact handling to CDI or leave it as it as (with factories).
Actually the current system is quite good and not related to managed beans.
Yes, moving the internal artefact handling to CDI is not yet a given, especially not for new artefacts. The consideration might be different for new artefacts.
Using CDI for this does have tremendous advantages though, not in the least that the implementation gets a lot smaller. I used this approach for Soteria (Jakarta Security implementation). There's no factory code or custom config files at all. Essentially CDI is the universal factory, and it saves quite a bit of time and effort using that instead of creating a set of factories again and again for each project.
Additionally, using CDI one can apply decorators, interceptors, alternatives, veto, etc using the standard CDI APIs.
Not all is perfect though, the CDI APIs to do this can be a little rough around the corners. I've posted several issues and suggested enhancements to make a few of those things a little bit easier.
p.s. as for the REST lifecycle mentioned above, I just found a good example in the Mojarra tests for its use:
<!DOCTYPE html>
<f:metadata>
<f:viewParam name="page" value="#{userBean.page}" />
<f:viewAction action="" />
</f:metadata>
<head>
<title>Never shown</title>
</head>
<body>
<p>Never shown</p>
</body>
</html>
I've seen such pages in actual apps too. With the REST lifecycle, a view action can be directly handled by a bean without having the largely useless page delegating to it.
Kind regards,
Arjan Tijms
