jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: Status for Arjan Tijms

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Tue, 24 Jan 2017 10:17:16 +0100

Hi,

Thanks for the correction, indeed, the FacesContext bug, and yes breaking
after an include or forward.

I'd love to fix it, but there's almost no time left. If pure fixes can
still be done in the 2.3 branch before the final is announced, that may be
an option.

Kind regards,
Arjan



On Tue, Jan 24, 2017 at 8:03 AM, Bauke Scholtz <balusc_at_gmail.com> wrote:

> The FacesConfig bug? You mean the FacesContext breaking after an include
> or forward? I find this has to be fixed before final.
>
> Cheers, B
>
> On Mon, Jan 23, 2017, 20:28 arjan tijms <arjan.tijms_at_gmail.com> wrote:
>
>> Hi,
>>
>> On Wed, Jan 11, 2017 at 5:25 PM, arjan tijms <arjan.tijms_at_gmail.com>
>> wrote:
>>
>> Basically working on the items from my previous mail step by step. 1435
>> is done, I haven't had a reply or +1 for the switch so I'll not look at
>> that. Now looking at the last things for the VDL I mentioned. FacesConfig,
>> well it's a bug and we may be able to fix that in the impl. later.
>>
>> Will look at the PDF spec text later tonight.
>>
>>
>> Just to confirm this, the VDL was done via issue https://java.net/jira/
>> browse/JAVASERVERFACES_SPEC_PUBLIC-1260
>>
>> Today I added the last test for it. Before that I spend some time
>> migrating a related Cactus test.
>>
>> The FacesConfig bug indeed wasn't addressed so this could be mentioned as
>> a known bug or known limitation.
>>
>> With that I think everything from this mail thread had been addressed,
>> either done or confirmed to be dropped.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>> On Wed, Jan 11, 2017 at 3:52 PM, manfred riem <manfred.riem_at_oracle.com>
>> wrote:
>>
>> Hi Arjan,
>>
>> Is there anything left?
>>
>> Thanks!
>>
>> Kind regards,
>> Manfred Riem
>>
>> On 1/5/17, 8:51 AM, arjan tijms wrote:
>>
>> Hi,
>>
>> I'm working on finalising JAVASERVERFACES_SPEC_PUBLIC-1435, for which
>> several commits have been done earlier.
>>
>> While working on this I noticed that the JSP VDL may get in the way in
>> some cases. There is currently a switch to switch off the Facelets VDL, but
>> there is not one to switch off the JSP one. I'd like to propose to add a
>> switch for the latter as well.
>>
>> After finishing JAVASERVERFACES_SPEC_PUBLIC-1435, hopefully today or
>> tomorrow, I'll continue to look at the faces config issue. The most
>> important bits of it have been committed earlier, so it's a matter of
>> adding the remaining config options to it.
>>
>> Closely related to JAVASERVERFACES_SPEC_PUBLIC-1435 I'd like to see if
>> we can say something in the spec to support an exact mapping. E.g. if the
>> FacesServlet is mapped to /foo/bar (exact mapping) and a physical resource
>> /foo/bar.xhtml exists, then recognise /foo.bar. This basically already
>> happens when used in an outcome for the navigation handler.
>>
>> Then there's still the matter of injecting the FacesContext. This now
>> breaks after an include or forward. Something must be done there.
>>
>> After that, just double check everything. Check the Javadoc for typos,
>> double check if names are clear and consistent, etc.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>> On Thu, Jan 5, 2017 at 4:41 PM, manfred riem <manfred.riem_at_oracle.com>
>> wrote:
>>
>> Hi Arjan,
>>
>> How are things progressing? What work is left?
>>
>>
>> Thanks!
>>
>> Kind regards,
>> Manfred Riem
>>
>> On 12/5/16, 9:45 AM, arjan tijms wrote:
>>
>> Hi,
>>
>> I have code for the getResourcePaths and Configuration. Config code, see
>> here: https://github.com/jsf-spec/mojarra/tree/config
>>
>> These two should be doable to be done soon, say 2 weeks from now.
>> Depending on how things go, "extensionless base" may have to be dropped.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>> On Mon, Dec 5, 2016 at 5:40 PM, manfred riem <manfred.riem_at_oracle.com>
>> wrote:
>>
>> Hi Arjan,
>>
>> From the 2) category which ones can you complete soon?
>> And which ones might have to be dropped?
>>
>> Kind regards,
>> Manfred Riem
>>
>>
>> On 12/5/16, 9:29 AM, arjan tijms wrote:
>>
>> Hi
>>
>> On Mon, Dec 5, 2016 at 4:24 PM, manfred riem <manfred.riem_at_oracle.com>
>> wrote:
>>
>> Can you please tell me what you
>>
>> 1) have done
>>
>>
>> * Class level bean validation - 1 (only did bits and pieces for this one)
>> * Support for custom types in UIData and UIRepeat - 1078
>> * Support for the Iterable interface in UIData and UIRepeat - 1103
>> * System event published after view rendered - 1135
>> * Injection and EL resolving of JSF artefacts - 1316
>> * Injection in more JSF artefacts - 1316
>> * Support for the Map interface in UIData and UIRepeat - 1364
>> * Native managed beans annotations deprecated - 1417
>> * CDI compatible @ManagedProperty - 1418
>>
>>
>> 2) are currently doing
>>
>>
>> Configuration - 1416
>>
>> Work is done in public branch in our personal Github repo, but I never
>> merged it into the master
>>
>> Extensionless URLs base - 1260
>>
>> Small basic changes for extensionless URLs to be easier. Was originally
>> waiting for the "mapping API" to appear in a GF 5 build.
>>
>> getResourcePaths like method for ResourceResolver - 27 jul, EG list
>>
>> Resource resolver being able to provide a list of what resources it
>> provides.
>>
>>
>> 3) are not going to do
>>
>>
>> Easy components and Facelets tag enhancements as extensively discussed
>> throughout the spec cycle. I absolutely would have loved to be doing these,
>> but there's just no time left :(
>>
>>
>> And for 1) and 2) if there is going to be a need for any text in the
>>
>> Specification (the PDF document).
>>
>>
>> The UIData and UIRepeat support for extra types are listed in the spec
>> document and that list would have to be extended.
>> Implicit objects can not be resolved via CDI totally bypassing the JSF EL
>> resolver for these objects, which should be mentioned in spec text.
>> There's 1 new implicit EL object which should be mentioned
>> Native managed beans annotations being deprecated should be added to
>> deprecated section in spec document
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>> Kind regards,
>> Manfred Riem
>>
>>
>>
>>
>>
>>