[
https://issues.apache.org/jira/browse/MYFACES-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13788082#comment-13788082
]
Gerhard Petracek commented on MYFACES-3797:
-------------------------------------------
@ #1
"changing the default behavior of the state handling algorithm"
that isn't correct. the state-handling of this part saves/restores the class of
the artifact. that wasn't changed at all.
the previous code is:
restoredObject = clazz.newInstance();
and now the class is used for a bean-lookup (if the feature is enabled) and
only if there is no bean (or the lookup was skipped because the feature isn't
enabled) "clazz.newInstance()" is used (like before).
@performance:
isAssignableFrom is fast and we can tweak resolveExternalArtifact for the
default case.
i thought about an adapter already, but it breaks #getConverter and
#getValidators (if we are talking about the same).
@ #2
see my updated comment.
@"cdi storage" once #2a of my previous comment works, we need the
storage-approach for the cleanup (esp. for @PostConstruct methods) of
dependent-scoped beans which are serializable. the alternative is a full
tree-visit, which is way slower.
@ #3:
yes and it works. in case of normal-scoped beans the cdi-container handles the
lifecycle and in case of dependent beans we remove them at the end of the
request (as it is done implicitly for non-cdi converters/validators).
no - StateHolder doesn't require them to be view scoped, because instead of
creating a new instance manually (that's what we have now), the cdi-container
will provide a new instance in case of dependent scoped converters/validators
(or the instance managed by the cdi-container in case of normal-scoped beans)
and in all those cases the state gets restored the same way (via #restoreState).
@view-scope:
once #2a is fixed, i'll show it with an example.
(@"passivation capable scope" yes and we don't have an issue here at all)
@ #4
yes - you will get a std. cdi-proxy for normal-scoped beans. maybe that's the
point you need to know to understand the approach.
@ 3rd party libs. i know what you mean, however, with this patch we can fix all
issues all other (known) approaches have. if 3rd party libs use their own
implementation for state-handling, they are responsible to handle state
correctly.
@tests:
+1
i did them manually and all cases worked so far (the only exception is #2a of
the previous comment due to an issue with that part of our current state-saving
-> i just can test my local addition once serializable converters/validators
get restored as well. before that we don't have the issue at all.)
> 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)
