File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JSF and the fly likes JSF SessionScoped Beans Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "JSF SessionScoped Beans" Watch "JSF SessionScoped Beans" New topic
Author

JSF SessionScoped Beans

Marco Noronha
Ranch Hand

Joined: Oct 30, 2012
Posts: 50
Guys,

I´m using Spring and JSF 2 and Tomcat.. but I´m having alot a problems due the lack of ViewScope on Spring.
Because of that, I´m thinking on the fallowing solution:

But my managedBeans as sessionsBeans and remove them manually.
I know exactly when to remove them. Let´s imagine the pages:
p1, p2, p3, p4. And I have a SessionScoped Bean with is: MyBean (#{myBean}.

Now lets go to the scenerious:

- User access "p1" with has #{myBean} reference. The bean is created and now on sessionMap.
- User navigates to "p2" witch also has #{myBean} reference. THE BEAN STAYS ALIVE.
- User navigates to "p3" witch DOESNT have myBean reference. BEAN is removed from sessionMap
- Garbage Collector will clean the null instance from server menory

And that goes on and on...

What do you guys think about that?
How can i implement something like that?

PS: I saw My Faces extentions that does exacly that. But didn´t work for me because of CDI problems! I googled it ,
and the only person that I found that had the same problem gave up! The solution offerted was to change tomcat to glassfish. And
that is something I dont want to do.

PS 2: ViewScoped didn´t work as well. Not even those "ViewScoped for Spring 3" blog post's workarounds didn´t work.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16303
    
  21

Actually, Spring works just fine with ViewScope. I do it all over the place.

The main thing is, I'm not using Spring to instantiate the View-scoped beans, they're bog-standard JSF Managed Beans. But I so inject my ORM and other services that are Spring beans into these View-scoped objects.


Customer surveys are for companies who didn't pay proper attention to begin with.
Marco Noronha
Ranch Hand

Joined: Oct 30, 2012
Posts: 50
Tim Holloway wrote:Actually, Spring works just fine with ViewScope. I do it all over the place.

The main thing is, I'm not using Spring to instantiate the View-scoped beans, they're bog-standard JSF Managed Beans. But I so inject my ORM and other services that are Spring beans into these View-scoped objects.


Yeah, but then your managed bean is:


?

Because if I remove the @Component, I get an error... Don´t know if it is because I use @Autowired and stuff.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16303
    
  21

My suspicion is that you are attempting to use JSF ManagedBeans as some sort of non-Model objects. ManagedBeans are best used only for the UI backing beans. Let Spring handle the rest.

Also, stacking Component and ManagedBean annotations is potentially causing 2 instances of the bean to be constructed, since one directive controls JSF and the other controls Spring. Since they share a namespace, you wouldn't notice it right away, but some really obscure bugs could develop.

If you're looking for a short-term Spring bean, you may need to do some homework. Most of my Spring beans are, in effect, Application-scoped. Meaning that while they're not literally in J2EE Application Scope, they're global singletons of long-term duration.
Marco Noronha
Ranch Hand

Joined: Oct 30, 2012
Posts: 50
I see we are jumping out of the subject ... I mean, we are trying to find a alternative solution..
But, again, is there a way to implement all bean sessionScope and then remove them manually (just like i discribed)
when I don´t need them?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16303
    
  21

Marco Noronha wrote:I see we are jumping out of the subject ... I mean, we are trying to find a alternative solution..
But, again, is there a way to implement all bean sessionScope and then remove them manually (just like i discribed)
when I don´t need them?


The "proper" way (as of JSF2) is to create a Custom scope. However, this isn't something that's well-documented and it's pretty cumbersome in its current form, I think.

What I did in JSF1 (and have carried over to some JSF2 apps) was to implement a utility method for destroying unwanted session beans and place it in my catch-all JSFUtils class, where I hide the framework-dependent code.

Since a JSF session bean is just a plain J2EE session object that just happens to be constructable and injectable by the FacesServlet in accordance with the bean annotations (or faces-config), you can get rid of the object just by obtaining the J2EE session and doing a removeAttribute on the name of the object. If a subsequent JSF request is made for that object, a new one will be created on demand.
Marco Noronha
Ranch Hand

Joined: Oct 30, 2012
Posts: 50
Yeah that is the idea.

I just don´t know how I´m doing that?
In a ServletFilter? In a PhaseListener?

And besides, I only want to kill it if the next page DOESN´t have a reference to it..
So how can I Scan the next page XHTML and see if my "myBean" is referenced there? #{myBean}

And there´s another thing too.. I´m using composite components, so.. when I intercept the page...
Will I have all the html mounted? Because I pass only the controller to the component and HE calls the methods
witch is a patters (default - abstract MB).

I don´t know if my english is 'understandable' sorry if its not!
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16303
    
  21

Don't over-complicate. Just remove the bean as part of the POJO action method code. If you're doing proper Inversion of Control, you can inject the destination page's backing bean into the backing bean for the current page OR you can share a session-scope bean between the old and new View backing beans (also injected).

You don't have to worry about "View Mounting". In JSF, the HTML is rendered by the render-results phase of the application lifecycle. This phase happens after all user code (including the action method) has completed execution and the model objects are already fully up to date. The only cases where user-written code would have an impact was if platform-specific user-supplied junk had been wired into the render-response process. If you're not familiar with the internal workings of JSF you shouldn't be doing that, and if you are familiar with the workings of JSF you won't want to do that.
Marco Noronha
Ranch Hand

Joined: Oct 30, 2012
Posts: 50
Tim Holloway wrote:Just remove the bean as part of the POJO action method code. If you're doing proper Inversion of Control, you can inject the destination page's backing bean into the backing bean for the current page OR you can share a session-scope bean between the old and new View backing beans (also injected).


But what will be the scope of my bean, since i dont have viewscope (Spring issue) ?
It needs to be session so ajax datatable and other stuff works
(and besids that I have a DynaFormModel that needs to be preserved, because it holds the fields that the person is using on the filter)

I can´t just do:


<!-- this is what I have NOW -->
<p:commandButton id="edit" icon="ui-i con-pencil"
action="#{cc.attrs.controller.getFormPath}" ajax="false">
<f:setPropertyActionListener value="#{entity}" target="#{cc.attrs.controller.entity}" />
</p:commandButton>

<p:commandButton id="delete" icon="ui-icon-trash" onclick="confirmation.show()">
<f:setPropertyActionListener value="#{entity}" target="#{cc.attrs.controller.entity}" />
</p:commandButton>

<!-- this is what it would look like, as you said (I THINK) -->
<p:commandButton id="edit" icon="ui-i con-pencil" actionListener=edit(#{entity})
action="#{cc.attrs.controller.getFormPath}" ajax="false" />

<p:commandButton id="delete" icon="ui-icon-trash"
onclick="confirmation.show()" actionListener="delete(#{entity})" />



Actually I don´t know if the delete would work, because I have a confirmDialog.. But that is the least of my problens...
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16303
    
  21

Spring shouldn't be constructing the JSF backing beans. They should be JSF Managed Beans, and that allows View Scope. The JSF constructors can inject Spring beans into JSF Managed Beans as Managed Properties, but you shouldn't use Spring to try and inject stuff into JSF Managed Beans.
Marco Noronha
Ranch Hand

Joined: Oct 30, 2012
Posts: 50
Tim Holloway wrote:Spring shouldn't be constructing the JSF backing beans. They should be JSF Managed Beans, and that allows View Scope. The JSF constructors can inject Spring beans into JSF Managed Beans as Managed Properties, but you shouldn't use Spring to try and inject stuff into JSF Managed Beans.


HERE is how I´m trying to do what you are saying:



But now, AJAX doesn´t work (not even the primefaces datatable!!)... And I also put everything in one view...

I mean:

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JSF SessionScoped Beans