2 things that trigger automatic tirades from me are Do-It-Yourself login/security systems and NetBean's sloppy terminology. Sorry if it gets old, but there are important reasons why I keep blindly repeating this stuff. In the case of the "Controller" issue, it's not just that mis-naming the generated classes causes people to wrongly perceive how JSF is working, there are people who try to actually make backing beans work as Controllers, which denies them the simplicity of how JSF really does work (and ultimately leads to less reliable, more expensive "solutions"). So please forgive me.
Anyway, I have lots of examples of how to use Spring JPA with JSF. Unfortunately, most of them are in proprietary code.
Just a general overview, though. First, my standard architecture for this approach is that I have 2 persistence logic tiers plus the entity beans. The upper tier ties to the app's business logic and handles transactions involving multiple tables and other complex issues. The lower tier is my DAOs, which mostly have the basic find/CRUD functions of a single table per DAO (although in some cases, a parent/child table relationship gets both tables in one DAO).
My upper-tier persistence ("service") modules provided the demarcation between detached and transactional entities. I don't like the common practice of holding a database connection over from the business logic to the display rendering services - too many opportunities to zap something accidentally - so I invoke a persistence-service method to fetch a "working set" of detached entities that the business and display functions can use, and then if/when I'm ready to update them, I invoke a "save" method in the persistence-service tier that merges the changes with the actual ORM system and - where applicable - returns a new copy of the working-set objects (ORMs have a habit of returning objects that are equal, but not identical when merged).
There's a Spring-JSF bridge functionaility that allows me to code EL references to any Spring-managed bean, and I use that to inject the persistence service components into my JSF backing beans so I don't have to go out and fetch them. The persistence services and DAO classes carry a Spring annotation of "@Repository", which tells Spring that I'll be using them that way. They also carry the @Transactional annotation, because, as I said, the persistence service methods each comprise one database transaction. DAO's run under the services method transaction context.
In practice, this makes for a very tidy arrangement that's easy to implement, easy to understand, and easy to maintain.
Now on to your specific problem. You essentially need to determine whether the fault is in your not fetching the data or in PrimeFaces not rendering it once it's fetched. I haven't worked with PrimeFaces in a while, so I hope someone who has some PrimeFaces expertise will read this
thread and offer some advice. I know at least one shop in my own town that's stuffed with PrimeFaces workers, but alas, I'm not considered worthy to associate with them and I don't know of any of them hanging out on the Ranch.
Be that as it may, one thing I've learned is that @PostConstruct isn't as wonderful as it would appear. It's only invoked once, right after the bean is constructed (hence the name), and in JSF, sometimes this is not often enough. Instead of using PostConstruct methods, I've found that a more productive approach is to do "load-on-demand". Meaning that I do the actual loading of the data as a sub-function of the data's property-get method. For performance reasons, I cache this data (since "get" methods can easily be invoked 5-6 times in a single request). Then, if I need a fresh copy, I simply null the cache so that the next "get" triggers a reload. It's not as straightforward as a @PostConstruct, I suppose, but it's more flexible.