Hi,
On Tue, Oct 14, 2014 at 8:55 PM, Neil Griffin
<neil.griffin_at_portletfaces.org> wrote:
> In addition, the PrettyFaces servlet filter causes an issue with the JSF 2.2
> h:inputFile component in Tomcat:
> http://stackoverflow.com/questions/8047173/how-to-enable-multipart-form-data-in-tomcat-7-0-8-server/8050589#8050589
>
> I think that whatever we define for url mapping should not rely on servlet
> filters.
The problems with Servlet Filters and specifically forwards (which if
I'm not mistaken is what PrettyFaces uses exclusively) are rather well
understood I think.
In OmniFaces we also took a stab at solving this issue (simple
extensionless views, not elaborate arbitrary mappings) with our
FacesViews feature. Next to the Filter and Forward approach that
PrettyFaces and a couple of others use, we have another approach (it's
the default since OmniFaces 1.4 actually). With this approach we do an
upfront scanning of the available top level Facelets, and use the
Servlet 3.0 programmatic mapping feature to programmatically do a
"Servlet exact mapping" (i.e. mapping without patterns) of each
encountered Facelet on the FacesServlet.
We do use a Filter anyway, but it's to wrap the request in order to
fool JSF that it's a normal request (otherwise it's prefix/suffix
mapping heuristics would fail).
If this was done within the core JSF implementation then obviously no
Filter to fool itself would be needed. I've documented the approach
here:
http://omnifaces.org/docs/javadoc/1.8/org/omnifaces/facesviews/package-summary.html
and posted an article about it here:
http://arjan-tijms.omnifaces.org/2013/03/easy-extensionless-urls-in-jsf-with.html
Related to this is a Servlet issue I created some time ago that asks
for the Servlet container to reveal the mapping they chose to
interpret the incoming URL. The container of course has this
information, while JSF has to use complicated heuristics to reverse
engineer it. See
https://java.net/jira/browse/SERVLET_SPEC-73
Specifically with Ed as the co-spec lead on Servlet I hope
SERVLET_SPEC-73 can be given some serious consideration.
Kind regards,
Arjan
Also, it would need a flexible API that the JSF Portlet Bridge can
> use to integrate with portal-vendor-specific friendly URLs.
>
>
> Best Regards to all,
>
> Neil
>
> On Oct 14, 2014, at 1:28 PM, Cagatay Civici <cagatay.civici_at_gmail.com>
> wrote:
>
> Hi Cagatay,
>
> I'd also like to see some url mapping stuff as a big ticket. I've done this
> for a customer and it is really not so complicated to implement. I will
> share the ideas (which are basically borrowed from PrettyFaces) after my
> holidays in 2 weeks.
>
> Ciao Frank
>
> Great, looking forward to hearing your feedback.
>
> Cagatay Civici
> PrimeFaces Lead
> PrimeTek Informatics
> www.primefaces.org
>
> On Tuesday 14 October 2014 at 20:25, Frank Caputo wrote:
>
> Hi Cagatay,
>
> I'd also like to see some url mapping stuff as a big ticket. I've done this
> for a customer and it is really not so complicated to implement. I will
> share the ideas (which are basically borrowed from PrettyFaces) after my
> holidays in 2 weeks.
>
> Ciao Frank
>
> Am 13.10.2014 um 15:37 schrieb Cagatay Civici <cagatay.civici_at_gmail.com>:
>
> Hi,
>
> We need 2 or 3 big ticket features in JSF 2.3.
>
> My big ticket offer would be related to url mapping.
>
> For example app/user/ maps to WEBAPP/pages/userpages/user.xhtml
>
> I don’t think it is very hard to do in terms of implementation as well.
>
> Would be good to have a configuration by exception just like the rest of
> Java EE by following a certain convention of mapping.
>
> Regards,
>
> Cagatay Civici
> PrimeFaces Lead
> PrimeTek Informatics
> www.primefaces.org
>
> On Monday 13 October 2014 at 16:22, Bauke Scholtz wrote:
>
> Hi,
>
> How about a native push component using websockets which is new since Java
> EE 7?
>
> Cheers, Bauke
>
> On Oct 13, 2014 3:00 PM, "Josh Juneau" <juneau001_at_gmail.com> wrote:
>
> I listened to the audio from the expert group meeting at JavaOne. I
> apologize again that I could not make it due to one of my talks being
> scheduled at the same time. That said, it seemed as though the meeting went
> very well, and I was happy to hear that there are others (Neil in
> particular) that also would like to see at least one big ticket item for JSF
> 2.3.
>
> I feel that it is important to have at least one feature that will catch the
> attention of the community...mainly because such features help to maintain
> the visibility of technologies. If there are no big ticket items in 2.3,
> then it may be overlooked by some, making it look like JSF is becoming a
> waning technology...falling to the single-page frameworks, or being pushed
> aside for the MVC initiative. We all know that JSF is still widely used and
> excellent at what it does, but I think JSF needs to remain highly visible
> with the 2.3 release as the leading server-side web framework for Java EE,
> especially given that there are a couple of years between each release.
>
> Maybe the big feature could be the "decorate response" phase that was
> mentioned in the meeting, or even "increased support for HTTP 2.0", covering
> the dispatch priority concerns. Perhaps better integration with single-page
> frameworks, as addressed in Ian's presentation?
>
> Thanks for your time, I appreciate it.
>
> Josh Juneau
> juneau001_at_gmail.com
> http://jj-blogger.blogspot.com
> https://www.apress.com/index.php/author/author/view/id/1866
>
>
>
>