[
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794609#comment-13794609
]
Leonardo Uribe commented on MYFACES-3786:
-----------------------------------------
Let's be clear about this. LifecycleProvider is needed to inject servlet 2.5
annotations into jsf managed beans. How we handle the injection depends of the
JSF artifacts that needs to be injected. So, the inclusion of a new logic there
depends on the lifespan the JSF artifact that needs to be injected.
I think maybe in this point we are thinking too far. We don't really need to
take care about that.
It is necessary a storage in jsf to store the injected instances via
InjectionProvider? Depend of the injected artifact. Since all artifacts are
instantiated by JSF, we can just take them from their locations. For example,
in FactoryFinder there is already a map holding the factory instances, so why
create another storage to get the same?. On the other side, SystemEventListener
requires a place to hold those references (RuntimeConfig) because we can access
it directly from Application object. How that is implemented is responsibility
of JSF, that's it. If there is a need to do an external lookup from CDI
perspective it is ok to do so. That's not a big deal.
Simplicity, that's the key point. Impose a storage as a map sounds too
restrictive and complex for something that can be as simple as just say "inject
this JSF artifact that has applicationScope lifetime". If in the future
InjectionProvider needs a change it will be for 2.3 or upper versions, it is
more, maybe we will not need of it and instead we'll be forced to deprecate it.
I'm starting to think the solution right now in trunk is ok, I don't like to
hold a map in the provider because it is something inherently "broken by
design", that only requires a change in the spec to fail or create a memory
leak, but it will work for now. After all, "... the alternatives can become a
lot much worse ...".
> Web Container injection support should be provided for additional lifecycle
> artifacts (not just managed beans)
> --------------------------------------------------------------------------------------------------------------
>
> Key: MYFACES-3786
> URL: https://issues.apache.org/jira/browse/MYFACES-3786
> Project: MyFaces Core
> Issue Type: Task
> Components: JSR-344
> Reporter: Leonardo Uribe
> Assignee: Leonardo Uribe
> Fix For: 2.2.0
>
> Attachments: cdiELresolverWeb.zip, cdiELResolver.zip,
> cdiPartialViewContext.war, cdiPartialViewContext.zip, cdi.patch,
> cdiphaselistener1.patch, cdiphaselistener2.patch, cdirevised.patch,
> cdiValidatorSource.zip, cdiValidator.war, MYFACES-3786-1.patch,
> MYFACES-3786-2.patch
>
>
> This issue is all about how to inject beans into jsf artifacts.
> See JSF 2.2 section 5.4.1
> The problem here is in some point we need to give the control to the
> underlying environment to inject beans into the artifacts, but we don't know
> much about how to properly do it, so we need to try with examples.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
