[ https://issues.apache.org/jira/browse/MYFACES-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13788512#comment-13788512 ]
Leonardo Uribe commented on MYFACES-3797: ----------------------------------------- I think the best way to analyze the advantages or disadvantages is to try to forecast the future a bit. Suppose you have a custom input component that does not extend from UIComponentBase but from UIComponent and you need to write the state saving logic. What do you do? you read the spec, and make custom implementations based on the descriptions there. But you haven't realized that small detail done inside UIComponentBase or DeltaStateHelper, that has changed the behavior of a method that has a clear description in the spec javadoc. At the end, your code will not work, because from outside you don't know what's inside myfaces code. And the solution? do some ugly myfaces specific hack that only god knows how to do in your third party code and you'll pray that on further versions it will not get broken. On the other side, the solution using an adapter just introduce a fine layer between the converter validator implementation and the component tree, that will be added only in those cases where CDI injection is required, so by default it is disabled. Using FacesWrapper, we can always get the inner instance. Will the existing code keep working? Yes, of course, remember the wrapper is optional. Now the question is which third party libraries do a type check over the new converter / validator instances that are injected. But more important than that is just using the spec, the third party developer can do the necessary code to inspect the wrapper and check the type correctly. In fact, the code is just trivial. Do we care about existing 3rd party libs for a new feature to be added in MyFaces 2.2.x and that by default is disabled? Absolutely no. That's a load that we don't require to carry on. JSF 2.2 is a major release, it is reasonable to write 2.2 versions of the libraries affected, but remember FacesWrapper is there since 2.0, so the necessary code can be added in 2.0 branches as well. In this case, we have a solution that just breaks encapsulation principle (which means you don't need to know what's inside the code to make it work together) against another (using an adapter) that does not. Now the state problem. To be clear, with a wrapper we don't add state. How is that possible? You can make the wrapper implement PartialStateHolder and with that the problem is solved. I know that, because there are some examples inside MyFaces Core that do precisely that. Write the wrapper can be tricky, but it will work, no doubt about that in my mind. The solution using the adapter could be discussed and included in the spec. Inclusive, we can make an SPI interface for this one. What's the deal about the adapter solution? there is no problem, it is feasible and its drawbacks are minimal compared with the alternative. > 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_2.patch, 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)