Hi Manfred
I don't know. Sometimes different persons trying to solve the same problem
can find
different solutions.
The good news is we can make 2 or 3 at any time, even if it is not now. But
as I said,
I do not want to throw the towel for include this in JSF 2.3, not until I
do one last push.
regards,
Leonardo Uribe
2016-12-15 17:23 GMT-05:00 manfred riem <manfred.riem_at_oracle.com>:
> 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>:
>
>> +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> 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> 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> 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>
>>>>>>>> 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
>>>
>>> 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
>>>
>>>
>