[cdi-dev] [JBoss JIRA] (CDI-576) Provide an API to say a bean depends on another instance
Mark Struberg (JIRA)
issues at jboss.org
Fri Dec 18 15:27:00 EST 2015
[ https://issues.jboss.org/browse/CDI-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13143125#comment-13143125 ]
Mark Struberg commented on CDI-576:
-----------------------------------
@DependsOn in EJB is SERIOUSLY broken in practice. Imo we don't like that in CDI. Just touch that stuff in @PostConstruct and be done. If you create a loop then it will blow up anyway.
I cannot see what problem this should solve.
> Provide an API to say a bean depends on another instance
> --------------------------------------------------------
>
> Key: CDI-576
> URL: https://issues.jboss.org/browse/CDI-576
> Project: CDI Specification Issues
> Issue Type: Epic
> Reporter: Romain Manni-Bucau
>
> Sometimes you want to initialize a bean before another bean. This is typically the case of @DependsOn with EJB but it can be more vicious and through several layers.
> If A depends on B which depends on C then we can desire to initialize C before A but if A, B and C are normal scoped then it will not happen before C is touched before touching A.
> We can't guarantee we can find the dependency and it is not desirable to hardcode it sometimes (test mock shouldnt go in "main" code typically). That's why having an event (guess it will belong to extensions) allowing to require this kind of eager initialization can be nice.
> we would get something like
> {code}
> event.dependencyOn(bean1, bean2);
> {code}
> and it would be fired before after validation event.
> The runtime behavior will be to create bean2 before bean1 (I have no issue reversing params/renaming the method). Only trick will be for not normal scoped beans where we can need to reuse the same instance but it sounds feasible in term of implementation since we'll be in the "create" stack anyway.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
More information about the cdi-dev
mailing list