[
https://issues.apache.org/jira/browse/MYFACES-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13788047#comment-13788047
]
Leonardo Uribe commented on MYFACES-3797:
-----------------------------------------
#1
The patch adds some specific code inside, changing the default behavior of the
state handling algorithm. But what happen if the user implements directly a
class from UIComponent (for example Trinidad and other jsf libraries)? all that
code could be just ignored. Include that code also has performance
considerations, because most of the time it makes unnecessary checks. The nice
part about delegation pattern in this part is you can encapsulate the code that
do the injection or whatever in just one place and the "adapter" will deal with
the state issues (if is serializable, if is stateholder, whatever). The idea is
attach a "proxy" on the component tree that deal with CDI logic in those cases
where the converter or validator uses CDI injection.
#2
It becomes an issue when you think about pss algorithm. Where a serializable
converter should be stored? it the view scope? why there is an CDI storage for
something that should be "serializable"? now the view state is split in two:
one managed by jsf, the other in some cdi bag. I can see it could work, but we
need to do some tests first to be sure how to deal with this part.
#3
"converter/validator is StateHolder/PartialStateHolder" That's not necessary
true. A converter validator can be just a normal class, serializable,
stateholder or partialstateholder. The code that deals with that logic is in
UIOutput/UIInput. The real question is which is the default lifecycle for a
converter/validator in each case. In theory it should be request scope, but
maybe it is less than request scope. But if implements StateHolder it should
be view scope. I don't remember issues over the current implementation of view
scope. Remember view scope is a passivation capable scope, so all beans should
implement Serializable.
#4
What will be attached to the component tree? a proxy or the real instance? I
have never tried that, so I don't have idea about how the code works in that
part.
In conclusion, my doubts are more related about the interactions between the
state management and cdi and the aplicability of the solution for third party
libraries, even if I know the proposed patch could work.
> cdi support for converters and validators
> -----------------------------------------
>
> Key: MYFACES-3797
> URL: https://issues.apache.org/jira/browse/MYFACES-3797
> Project: MyFaces Core
> Issue Type: New Feature
> Components: JSR-344
> Reporter: Gerhard Petracek
> Assignee: Gerhard Petracek
> Attachments: MYFACES-3797.patch
>
>
> with
> <context-param>
>
> <param-name>org.apache.myfaces.CONVERTER_INJECTION_ENABLED</param-name>
> <param-value>true</param-value>
> </context-param>
> and
> <context-param>
>
> <param-name>org.apache.myfaces.VALIDATOR_INJECTION_ENABLED</param-name>
> <param-value>true</param-value>
> </context-param>
> it should be possible to enable cdi support for converters/validators.
> we need the config, because it was postponed for the spec.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
