3

After uncovering some potential performance issues I was having with Mojarra, I recently switched my application to run on MyFaces 2.1.10 implementation from Mojarra 2.1.7.

I have been using the OmniFaces SEO feature that allows for pretty extensionless URL's. This operates through the use of a servlet filter and is automatically enabled by adding a context parameter to the web.xml as well as adding a directory faces-views to WEB-INF that mirrors the xhtml document layout of web application.

I was a bit concerned about compatibility issues with Spring however, as I am utilizing the Spring Container and their custom EL resolver that replaces JSF dependency injection with Spring dependency injection, making every managed bean also a Spring bean. Even more worrying is that I am implementing Spring Security which also operates through the use of a servlet filter to intercept and authenticate incoming requests. My worry was that perhaps the two wouldn't work correctly if they happened to be invoked in a certain order.

Well the ExtensionlessURLS feature with Mojarra worked a bit different than what was described in the documentation

I noticed that to get it work in Mojarra, I simply had to leave my xhtml files in their original locations, however I needed to place an empty file of the same name and relative path in the faces-views directory. The filter seemed to recognize either extensionless or XHTML requests and display the page appropriately

When I switched to MyFaces however, this behavior changed where now the empty files in faces-views directory were causing a Premature EOF Exception to be thrown on page request. I noticed that to be able to serve both XHTML and extensionless requests that I needed to keep duplicate copies of the same page in both places.

I tried to work around this by having the file in faces-views do a and it found the source but the page wasn't loading correctly when I did this.

My question is, why am I seeing different behavior between Mojarra and MyFaces with ExtensionlessURLs? Could Spring Security by the reason for this? How can I work around this issue to where I do not need to keep two copies of the same source code in my project (clearly I am inviting silly errors and missed features by accepting this)?

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
maple_shaft
  • 10,435
  • 6
  • 46
  • 74
  • 3
    Not sure if it helps, but with `org.omnifaces.FACES_VIEWS_ENABLED` you can disable auto scanning (see package docs). Then follow Servlet 2.5 instructions and put faces views filter AFTER Spring Security. Having to put files in two places should never be needed ;) – dexter meyers Mar 08 '13 at 15:35
  • 2
    Things like OmniFaces and PrettyFaces work by forwarding to the FacesServlet. Did you try to add "forward" to the dispatcher types in web.xml? – Mike Braun Mar 08 '13 at 18:07
  • 2
    Arjan Tijms is still working on improving FacesViews for 1.4. I've brought this question under his attention. In the meanwhile, indeed try setting the dispatcher of the filters which are coming after to `FORWARD`. – BalusC Mar 08 '13 at 23:30
  • 2
    Using filters in combination with forwarding is never an easy task. For OmniFaces 1.4 I'm indeed working on an (additional) alternative approach. I've not yet used Spring Security, so I can't help with this directly right now, but maybe creating an issue over at https://code.google.com/p/omnifaces/issues/list is a better format for looking into this. I'm very curious though whether any of the suggestions posted here help. – Arjan Tijms Mar 09 '13 at 11:27
  • @BalusC Thanks for looking into this for me. I added FORWARD to the Spring Security filter and this seems on MyFaces to serve files in `faces-views` under both xhtml and extensionless. I was also able to delete everything in the root and keep just a single copy of markup files on the `faces-views` folder, so it seems to work correctly now. I had to make a few changes to support MyFaces so I can't just yet tell you how this affected the different behaviour in Mojarra. The only annoyance now is that the Eclipse integrated server needs to be restarted after every code change but thats doable. – maple_shaft Mar 11 '13 at 02:56
  • 2
    @ArjanTijms Thanks for responding, I am flattered that the original author of the feature decided to help :) I am sorry that I haven't been able to respond my life has been pretty crazy right now, but I can submit this as a possible issue either tomorrow or the day after. I am running on Servlet 3.0 so I haven't included anything special in my web.xml for Omnifaces but I can try the other suggestions and possibly try this with Mojarra as well just to see if things act any different. Thanks again and I am sorry that I have been slow to respond and provide information. – maple_shaft Mar 11 '13 at 03:02
  • You're welcome ;) I just published a new shapshot the other day that contains the alternative method that doesn't do forwarding. I still have to update the docs though. With this version you also don't necessarily have to put your files in a `faces-views` folder, but they can reside in the root. As for Eclipse, if you use JBoss tools there's a setting for controlling what gets hot deployed. If you set JSF in development mode new pages are automatically added to the FacesViews set of scanned pages (in non-dev mode, new pages indeed need a restart) – Arjan Tijms Mar 11 '13 at 08:00

0 Answers0