[
https://issues.apache.org/jira/browse/MYFACES-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13795191#comment-13795191
]
Leonardo Uribe commented on MYFACES-3786:
-----------------------------------------
#5 is way more complex. Now we need to create one instance of some class and a
full hashmap to inject one object. Doesn't that sound like JSF doing things
that CDI should do? In the integration code with a web server, doesn't that
sound just silly? I think it is inconvenient. The reason is no matter what we
put on InjectionProvider, the most probable outcome is that we need to
deprecate that in the future in favor to a better CDI integration.
Precisely what I want to avoid is end with a code in JSF that do things that
other library should do.
"... trying something only makes sense if you aren't sure about the result. we
know the result already - so trying something with obvious flaws doesn't make a
lot of sense. ..." In this case no matter what you put in InjectionProvider,
the most probably outcome is things will change. All solutions has flaws, the
question is which one is less worse. In my opinion, the less worse is the one
who avoid unnecessary complexity and put the code in the right place, so it is
#3 (using string for scope).
If #4 or #5 are the options, +1 to keep the code the way it is right now. In
the future, we can discuss how to deal with this in the context of JSF 2.3, and
how to fix this properly. There is no need to waste time in this for now.
Now going back to this solution:
public Object inject(Object instance) throws InjectionProviderException
public void postConstruct(Object instance, Object context) throws
InjectionProviderException
public void preDestroy(Object instance, Object context) throws
InjectionProviderException
It starts to looks even better. The inject(...) can return the context, so if
you don't have it, just return null, and if you have it, JSF only knows what it
needs to know: store the context somewhere to call postConstruct and
preDestroy. Simple, less classes, no unnecessary logic, no extra classes, no
extra object instantiation. After see the alternatives, I like this solution.
> 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, MYFACES-3786_bean-entry_draft_01.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)
