Here's another one I've spent quite a time trying to understand the issue.
Lets say I have an EJB declared as managed bean through faces config. This EJB (or better say, managed bean now) has several properties that are independent EJBs themselves. The are declared only as properties of the main managed bean. My IDE recognized the routes and give me access to secondary bean's properties. But when I put them as return values of the input fields only the "final" main bean's properties are getting the values while for every secondary bean declared there I get the "target unreachable, returned null" error/warning.
For better explanation here's an example.
faces config:form template:
So after submitting the form the error/warning is: target unreachable, address returned null
Wanna install linux on a vacuum cleaner. Could anyone tell me which distro sucks better?
I'm reading this superficially, but it sounds like you have encountered the Lazy Fetch problem.
JPA domain model objects by default do eager fetches of their primitive contents, but lazy fetches on their complex (JavaBean) properties. While you can present a domain model object in a Managed Bean, the necessary fetch/store mechanisms aren't accessed directly by JSF, so usually you'd front the actual domain model object with a container that holds that object and (often) its business-layer action services, which in turn would usually invoke the actual persistence services.
It still beats DTOs, though.
When this sort of architecture is used, typically, the connection between the domain model object and the persistence manager is severed just below the business layer, leaving you with a detached object. To get the missing child objects, you'd have to invoke persistency services again (JPA merge) and "touch" the indicated objects, tag the object as EAGER FETCH, define a Fetch Set, or force-fetch them in the code that does the parent object fetch. Or, you can add a filter that keeps the connection alive even after the return from persistency services. Which is a popular approach, but one I don't really recommend.
Customer surveys are for companies who didn't pay proper attention to begin with.
Thanks for you quick reply.
Since I am not very strong with EJB3 I'll ask.
What exactly should I change? In my EJBs for every related bean's getter or setter I have a declared fettchType using java annotation (for ex. @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY, mappedBy = "user")). I've tried to change fetchType to EAGER, but still I get the same error. So here go the questions:
- Should I change the fetchType only in my main bean getters or also in the secondray beans' related setters?
- Should I configure/change anything else besides that?
The actual solution had nothing to do with fetchTypes after all. And I hated using LAZY fech exactly for the reason of consuming too much memory.
The thing was that I had the objects created as they should when I tried to read them in a servlet for example (forgot to mention that, sorry). The actual problem lied in faces configs. Instead of mapping every bean property I just should have declared the beans alone with minimal properties which in my case were other managed beans only. The second key was to add to all referenced beans inside my main bean corresponding constructors so they become initialized no matter what. That's all, using this approach I could reach any dependency level.