Hi,
On Fri, Feb 10, 2017 at 4:53 AM, Leonardo Uribe <leonardo.uribe_at_irian.at>
wrote:
> Hi
>
> I found some more classes to remove:
>
> javax.faces.context.RequestCookieMap
>
This one is quite another type than the annotation, namely a class
implementing a kind of Map:
public class RequestCookieMap extends BaseContextMap<Object> {
private final HttpServletRequest request;
...
Or was there another reason to delete this one?
> javax.faces.context.SessionMap
>
Same for SessionMap:
public class SessionMap extends BaseContextMap<Object> {
private static final Logger LOGGER =
FacesLogger.APPLICATION.getLogger();
> javax.faces.view.ViewMap
>
This one indeed has to be deleted, thanks again ;)
Kind regards,
Arjan Tijms
>
> please remove these classes too.
>
> regards,
>
> Leonardo Uribe
>
>
> 2017-02-08 4:28 GMT-05:00 arjan tijms <arjan.tijms_at_gmail.com>:
>
>> Hi Leo,
>>
>> Good find! Sorry, this is my mistake, I moved a series of annotations
>> for javax.faces.annotation.* at some point and somehow that one was left
>> behind.
>>
>> Thanks!
>>
>> Kind regards,
>> Arjan Tijms
>>
>> On Wed, Feb 8, 2017 at 1:11 AM, Leonardo Uribe <leonardo.uribe_at_irian.at>
>> wrote:
>>
>>> Hi
>>>
>>> Checking the work done for better JSF - CDI integration, I found a
>>> duplicate class:
>>>
>>> javax.faces.annotation.ApplicationMap
>>>
>>> and
>>>
>>> javax.faces.application.ApplicationMap
>>>
>>> The second one must be removed.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>>
>>>
>>> 2017-02-04 5:33 GMT-05:00 Bauke Scholtz <balusc_at_gmail.com>:
>>>
>>>> Ed, how should I deal with the now indeed unnecessary port property in
>>>> UIWebsocket class? Spec or impl issue? It has indeed already been removed
>>>> from vdldoc, but just overlooked in UIWebsocket.
>>>>
>>>> Cheers, B
>>>>
>>>> On Sat, Feb 4, 2017 at 11:30 AM, Bauke Scholtz <balusc_at_gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I created https://java.net/jira/browse/JAVASERVERFACES-4223 for
>>>>> jsf.push script matter.
>>>>>
>>>>> As to context params, those are defined in PushContext.
>>>>>
>>>>> Cheers, B
>>>>>
>>>>> On Fri, Feb 3, 2017 at 11:26 PM, Leonardo Uribe <
>>>>> leonardo.uribe_at_irian.at> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> Looking for more issues, according to the javadoc of the public
>>>>>> review, I found UIWebsocket has "port" property. It should be removed,
>>>>>> because the URL is customized in ViewHandler. The spec documentation and
>>>>>> the vdldoc is ok, so the only place we need to fix is UIWebsocket. I can't
>>>>>> find where these two constants:
>>>>>>
>>>>>> javax.faces.ENABLE_WEBSOCKET_ENDPOINT
>>>>>> javax.faces.WEBSOCKET_ENDPOINT_PORT
>>>>>>
>>>>>> I was expecting them in ViewHandler.
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Leonardo Uribe
>>>>>>
>>>>>>
>>>>>> 2017-02-01 16:11 GMT-05:00 Edward Burns <edward.burns_at_oracle.com>:
>>>>>>
>>>>>>> >>>>> On Tue, 31 Jan 2017 22:24:13 +0100, Bauke Scholtz <
>>>>>>> balusc_at_gmail.com> said:
>>>>>>>
>>>>>>> EB> I suspect Bauke did that for a reason, but I would like to ask
>>>>>>> him to
>>>>>>> EB> make it be the same as Ajax, if possible. Bauke?
>>>>>>>
>>>>>>> B> Not a technical reason really. It was just a coding style which
>>>>>>> B> advocates encapsulation. It's possible to revert it to global
>>>>>>> B> style. I only wonder if I should create a spec or impl issue on
>>>>>>> this.
>>>>>>>
>>>>>>> Please create an impl issue and do the work in the
>>>>>>> MOJARRA_2_3X_ROLLING
>>>>>>> branch. Once it is safely integrated, please use git apply <patch>
>>>>>>> to
>>>>>>> apply it to master.
>>>>>>>
>>>>>>> >> Bauke, can we remove this? I can factually state it is not used
>>>>>>> anywhere.
>>>>>>>
>>>>>>> B> Indeed, it was a leftover of the initial proof of concept. It can
>>>>>>> safely be
>>>>>>> B> removed.
>>>>>>>
>>>>>>> Can you do this also in the same commit as the above work?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Ed
>>>>>>>
>>>>>>> --
>>>>>>> | edward.burns_at_oracle.com | office: +1 407 458 0017
>>>>>>> | 24 business days until planned start of JSF 2.3 Final Approval
>>>>>>> Ballot
>>>>>>> | 14 business days until DevNexus 2017
>>>>>>> | 39 business days until JavaLand 2017
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>