• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

JSF, EJB3 target unreachable, returned null

 
Akaine Harga
Ranch Hand
Posts: 99
Java MyEclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Tim Holloway
Saloon Keeper
Posts: 18302
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Akaine Harga
Ranch Hand
Posts: 99
Java MyEclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18302
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 99
Java MyEclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic