Hi Leonardo,
As previously stated we already did explore this early on in the 2.3
cycle and
have concluded it is too complex for its perceived benefits.
So I am going with your option 1 below.
Thanks!
Kind regards,
Manfred Riem
On 12/15/16, 3:10 PM, Leonardo Uribe wrote:
> Hi
>
> This is what says chapter 13 of java language specification
> section 13.4.17. final Methods
>
> https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html
>
> "... Changing a method that is declared final to no longer be declared
> final
> does not break compatibility with pre-existing binaries. ..."
>
> "... Changing an instance method that is not declared final to be
> declared
> final may break compatibility with existing binaries that depend on the
> ability to override the method. ..."
>
> LU> Can't we just remove the "final" modifier here? I know that in
> these cases
> LU> it makes sense, but make UIComponent instances injectable in CDI
> seems to
> LU> be a winning
> LU> proposition to me.
>
> EB> That sort of signature change would break existing compile time
> EB> dependencies and cause build time problems. We can't do that at this
> EB> point.
>
> I disagree. The Java Language Specification is clear about this. What
> happens
> here is if you change a "non final" method to "final", that breaks binary
> compatibility.
>
> The change proposed does not break binary compatibility.
>
> EB> You're not the only one. We tried to make UIComponent injectable and
> EB> ran into a lot of problems with state saving and the lifecycle. It's
> EB> too big a change at this point.
>
> Could be, but I do not want to throw the towel until try it. At this point
> we have 3 options:
>
> 1. Change the table to exclude UIViewRoot from injection.
> 2. Do the change removing "final" modifiers and include UIViewRoot as CDI
> injectable, do not inject components for current version.
> 3. Do the change and make components injectable.
>
> I ask you guys to reconsider, at least do option 2. Option 3 is still a
> posibility to explore, I'll do my best to see how to make it work.
>
> regards,
>
> Leonardo Uribe
>
> 2016-12-15 14:19 GMT-05:00 manfred riem <manfred.riem_at_oracle.com
> <mailto:manfred.riem_at_oracle.com>>:
>
> +1 on NOT doing API change
>
>
> On 12/15/16, 11:26 AM, Edward Burns wrote:
>
> Executive Summary:
>
> Ed pushes back on proposed API change.
>
> Details inline.
>
> On Thu, 15 Dec 2016 01:59:16 -0500,
> Leonardo Uribe<leonardo.uribe_at_irian.at
> <mailto:leonardo.uribe_at_irian.at>> said:
>
> LU> Hi
> LU> I'm exploring the posibility of make UIComponent
> instances CDI injectable
> LU> for JSF 2.3, and I have found that some final methods in
> UIComponent
> LU> creates a conflict:
>
> LU> public final Map<String,Object> getPassThroughAttributes()
> LU> public final TransientStateHelper getTransientStateHelper()
> LU> public final void popComponentFromEL(FacesContext context)
> LU> public final void pushComponentToEL(FacesContext context,
> UIComponent
> LU> component)
>
> LU> Can't we just remove the "final" modifier here? I know
> that in these cases
> LU> it makes sense, but make UIComponent instances injectable
> in CDI seems to
> LU> be a winning
> LU> proposition to me.
>
> That sort of signature change would break existing compile time
> dependencies and cause build time problems. We can't do that
> at this
> point.
>
> On Thu, 15 Dec 2016 02:14:42 -0500,
> Leonardo Uribe<leonardo.uribe_at_irian.at
> <mailto:leonardo.uribe_at_irian.at>> said:
>
> LU> I forgot to mention why this is really wanted. If
> UIComponents are
> LU> CDI proxyable we could make "binding" attribute to inject
> a CDI
> LU> UIComponent proxy and solve the problem when UIComponent
> instances
> LU> are inside session scope beans once for all. That could
> be a big
> LU> step forward for JSF.
>
> On Thu, 15 Dec 2016 10:34:05 +0300,
> Cagatay Civici<cagatay.civici_at_gmail.com
> <mailto:cagatay.civici_at_gmail.com>> said:
>
> CC> There are so many users who suffer from this issue for
> years, fixing
> CC> this will be great.
>
> While it is certainly true that users are suffering from the
> "binding"
> issue, which has been present since 1.0,
>
> On Thu, 15 Dec 2016 18:25:54 +0100, arjan
> tijms<arjan.tijms_at_gmail.com
> <mailto:arjan.tijms_at_gmail.com>> said:
>
> AT> Components are indeed explicitly not injectable now. See
> also the overview
> AT> table here:
> http://arjan-tijms.omnifaces.org/p/jsf-23.html#1316
> <http://arjan-tijms.omnifaces.org/p/jsf-23.html#1316>
>
> AT> A little over a year ago I had been experimenting with
> this too, and what
> AT> it basically needs (besides, indeed removing the final
> modifiers), is what
> AT> I called a "FacesRequestScope".
>
> You're not the only one. We tried to make UIComponent
> injectable and
> ran into a lot of problems with state saving and the
> lifecycle. It's
> too big a change at this point.
>
> Thanks,
>
> Ed
>
>