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, EJB3 target unreachable, returned null Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "JSF, EJB3 target unreachable, returned null" Watch "JSF, EJB3 target unreachable, returned null" New topic
Author

JSF, EJB3 target unreachable, returned null

Akaine Harga
Ranch Hand

Joined: Nov 03, 2009
Posts: 84

Hi again

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.

Managed bean:
faces config:form template:
So after submitting the form the error/warning is: target unreachable, address returned null

Any ideas?


Wanna install linux on a vacuum cleaner. Could anyone tell me which distro sucks better?
willCodeForFood("Java,PHP,C#,XML,VBS,XHTML,CSS,JavaScript,SQL"); //always looking for job opportunities in AU/NZ/US/CA/Europe :P
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

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.
Akaine Harga
Ranch Hand

Joined: Nov 03, 2009
Posts: 84

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?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

Any items with fetchtype LAZY won't be fetched when you're done with the persistence layer. And LAZY is the default for objects and collections.

However, don't go wild with eager fetched. A couple of bad things could happen. For example, in extreme cases, you can end up sucking the entire database into RAM.
Akaine Harga
Ranch Hand

Joined: Nov 03, 2009
Posts: 84

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.

Anyways, thanks for the help...
 
wood burning stoves
 
subject: JSF, EJB3 target unreachable, returned null