3

I've got an app running on Mojarra 2.1.1 / Glassfish 3.1 which has now grown to 150,000+ lines of code. The app uses ajax extensively with ViewScoped managed beans and the page-redirect-get pattern (i.e. faces-redirect=true).

One thing that is continually annoying me is the apparent lack of ease of passing parameters from page to page, and bean to bean (every page has it's own backing bean).

I've not been able to get the flash working. I typically need to access the data I've written to the flash in the preRenderView event listener of the next page. This doesn't work reliably, particularly after an application redeployment.

I've read up on CDI and have spent a few days trying to migrate from JSF managed beans to CDI beans, but can't get it to work. There seems to be a lot of compatibility issues between Seam 3 and Glassfish 3.1. I upgraded Weld to 1.1.1 but this doesn't help. From my perspective it just doesn't work at the moment. When I say doesn't work, for example I have a page trying to h:inputText into a String in the backing bean and this doesn't work, really simple stuff.

Because of the CDI problems I'm having I can't use seam-faces @RenderScoped which in a very simple test application (even on g/f 3.1) does just what I want, but not in the complex main application.

The only reliable mechanism I can find to use at present is URL parameters which are a security nightmare. Even though every effort is made to ensure that access to data is properly authenticated there's always the change of missing something, and seeing ...xhtml?id=51031 or whatever in the browser is too much for some people to resist trying other ids. I've written an obfuscation converter to avoid clear text and don't use meaningful names for the name/value pairs, but this doesn't get to the root of the problem.

I just wondered if I was missing something here, has everyone else got a working solution to this problem, even on glassfish? Am I worrying too much and should stick with URL params? Any other suggestions?

Thanks.

Oversteer
  • 1,778
  • 1
  • 22
  • 38
  • `I've not been able to get the flash working.` - can you elaborate on that? – akira Jun 20 '11 at 09:56
  • There is an issue with Mojarra reliably accessing values written to flash in the preRenderView listener of the next request. I logged a JIRA about a year ago and they're planning to fix it in Mojarra 2.2. The issue happens following an app re-deployment or server restart. There seem to be many use cases where flash doesn't work reliably. – Oversteer Jun 28 '11 at 12:40

2 Answers2

3

I saw the same. At the time I tried it Seam3 was very buggy and it's very hard to get it deployed to different servers. I switched to MyFaces CODI which worked without any problems from the very beginning. In your case you should have a look at @ViewAccessScoped. You can get rid of all those annoying workarounds.

Dar Whi
  • 822
  • 5
  • 14
  • 2
    As it happens I switched over to CODI ViewAccessScoped a few weeks ago and it's solved all my problems. In a few situations I'm also using conversation groups. This is definitely the way to go and is great advice. I wish I'd found this a year ago. For the benefit of anyone not using CODI note that it works fine with Mojarra and does not require the Myfaces implementation. If you are using ManagedBean and javax.faces.bean....Scoped annotations CODI intercepts these, so simply by adding the dependency to your project you can switch to CDI without making any code changes. Awesome! – Oversteer Aug 22 '11 at 11:49
2

Declare the parameters which you'd like to set or pass through to the next view in a

<f:metadata>
    <f:viewParam name="foo" value="#{bean.foo}" />
</f:metadata>

This does basically bean.setFoo(request.getParameter("foo")) during update model values phase of the GET request.

If you add includeViewParams=true parameter to the navigation outcome, then the ones which are declared as <f:viewParam> of the current view will be passed through to the next view.

public String doSomething() {
    // ...
    return "next?faces-redirect=true&amp;includeViewParams=true";
}

(note: the &amp; is important! the & won't work as it's not XML-valid)

The next view should have the same <f:viewParam> to get them to set in the bean. And so on.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • view parameters is what I'm using, sorry I wasn't clear, read all your blogs, Burns/Geary books, pages falling out. With non-persistent data like a registration page I could have 13 items of data, 13 X setPropertyActionListeners+f:viewParam. But only tryin to pass an object reference from page-to-page in same web container in same jvm. With persistent data got to pass primary key, have a converter, do EntityManager.getReference() in getAsObject() method. There's got to be a better way. Is there a session map solution that can handle clustering and multiple browser tabs? – Oversteer Jun 19 '11 at 01:30