[ https://issues.jboss.org/browse/CDI-576?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-576: ---------------------------------------- [~struberg] this is what I said (on the broken side) but it still needs a solution. "just touch that stuff" DOESNT solve anything since you have to know an API you can touch for proxies which is not obvious + as explained in the description you can not be able to do it if it is in several sublayers (it is more common that we think and why @DependsOn wouldnt even work in 50% of cases). See this very simplified case (jira pseudo-coding so please forget typo etc): {code} class InstanceManager { @Produces @ApplicationScoped MyInstance produce() { ... } void release(@Disposes MyInstance instance) {...} } {code} {code} class InstanceUsage1 { @Inject MyInstance instance; void start(@Observes @Initialized(AppScoped.class) Object start) { instance.doWork(); } } {code} {code} @Startup @Singleton // or any other start thing class InstanceUsage2 { @Inject MyWorker worker; @PostConstruct void init() { worker.startJobs(); } } {code} {code} class MyWorker { @Inject MyInstance instance; void doWork() { instance.doSomethingElse(); } } {code} This use case is : not orderable events (in previous samples the startup event) we need to be able to enforce dependencies to ensure the InstanceManager is started as expected at the very beginning. You can touch MyInstance in InstanceUsage1 but likely not in InstanceUsage2 where it is also needed. The case of startup is obvious and you can surely argue it is not 100% CDI - but it is real - but it is the same if you have a resource while would be hit later in the request/session/... and you need to validate it exists before starting the flow. Of course you can "touch" it but then if you mock it or specialize it your touching code can just be wrong and corrupt your application. Since we have the metadata in extensions I don't see any issue to ask for an eager instantiation there. Even adding constraints for such a feature (like scopes supporting it etc) is perfectly valid and fine but not having it makes some cases very hard to support IMHO. -- This message was sent by Atlassian JIRA (v6.4.11#64026)