• Post Reply Bookmark Topic Watch Topic
  • New Topic

What causes Backing Bean return null? How to resolve it?

 
Anirudh Lou
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello everyone I'm very new to javaweb and I tried to create my first javaweb project. However when some action were being invoke I received an error. Does anyone can help! Here is what I did:

Person.java



PersonEjbDao.java


FriendBean.java



show.xhtml




create.xhtml



details.xhtml




When tried to run my project what happened were:
1. When i clicked the link from show.xhtml



It output the page but without data being displayed.

but on the url it shows:

http://localhost:8080/javaeesample/faces/details.xhtml?pid=1

1. When i clicked 'Save' button in create.xhtml here is the error i received:

An Error Occurred:



I expand Stack Trace and it displayed



I don't know what makes my personBean.person.name null.

Any Help is very much appreciated.
 
Tim Holloway
Bartender
Posts: 18408
58
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The problem with posting full details of a project and asking for help is that too much info can be as bad as not enough. Since we're doing this for free, we're not motivated to print it all out and trace through all the details.

So what you often get is a rough guess answer based on common errors. And that's what you'll get here, at least to begin with. I realize that if you're new to JSF, you probably don't know what to include and what to omit, but I did want to make it clear why the first answer you get may not be the full answer or even the right answer.

There were 2 alarm-worthy items that jumped out at me when doing an early-morning blurry-eyed once-over scan of your samples.

1. You're using a Request scoped backing bean

2. There's a reference to a property value of a property within that bean.

Starting with #2. There's nothing wrong with that, but it gives a different error than when referencing a top-level property, which I'll explain shortly.

The real alam-ringer is #1. Rule #2 of JSF is that request scope is nearly 100% useless in JSF.

People coming from other platforms are used to using a lot of request-scope objects. They're convenient in that you use them and they get automatically discarded and there's no need to manually clean them up.

But that virtue is a fault in JSF, because JSF is designed to have multiple requests applied against the same model/view set. It's called postback and request scope fails for postback, precisely because a different instance of request scope object is constructed from scratch for each postback. There's no ongoing conversational state.

This most commonly causes problems when using the datatable and selection JSF controls, but in your case, what has probably happened is that a request was constructed on a PersonBean, its "person" attribute was set, then a postback occurred and the original PersonBean object was destroyed, since a Request scope object has a lifetime of only 1 single request. The postback cause JSF to construct a new PersonBean instance, but that doesn't cause any state information (such as the "person" attribute value) to be initialized, since JSF knows nothing about that data - it was lost when the previous instance was destroyed.

So, to explain item #2 in detail, you've referenced a brand-new PersonBean instance whose "person" attribute was uninitialized (null), then attempted to obtain the "name" property from that (null) object, which leads to a NullPointerException.

How to fix? You need to give the PersonBean a longer lifespan. In JSF1, that would mean session or application scope - generally session scope. Session scope, however doesn't automatically clean itself up. In fact, there's no native JSF function to remove old session-scope objects. That can be annoying as your app tends to accumulate a lot of useless outdated objects. So JSF2 has something called "View Scope". View Scope is a special variant of Session Scope where JSF will detect when you navigate to a new View and automatically purge the old view's session objects in the same way that request scope objects get purged when they are no longer useful.

SO:



Note that I omitted the @Named annotation, since the default naming for JSF backing beans is the bean's classname with the first character folded to lower-case, and therefore matches your explict @Named value.

Session-scope (including ViewScoped) beans must be serializable or your webapp server may complain. Even though ViewScoped beans have a shortened lifespan, it's still long enough that the server needs to be able to page it to backing store and/or pass it to another cluster node.
 
Anirudh Lou
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:The problem with posting full details of a project and asking for help is that too much info can be as bad as not enough. Since we're doing this for free, we're not motivated to print it all out and trace through all the details.

So what you often get is a rough guess answer based on common errors. And that's what you'll get here, at least to begin with. I realize that if you're new to JSF, you probably don't know what to include and what to omit, but I did want to make it clear why the first answer you get may not be the full answer or even the right answer.

There were 2 alarm-worthy items that jumped out at me when doing an early-morning blurry-eyed once-over scan of your samples.

1. You're using a Request scoped backing bean

2. There's a reference to a property value of a property within that bean.

Starting with #2. There's nothing wrong with that, but it gives a different error than when referencing a top-level property, which I'll explain shortly.

The real alam-ringer is #1. Rule #2 of JSF is that request scope is nearly 100% useless in JSF.

People coming from other platforms are used to using a lot of request-scope objects. They're convenient in that you use them and they get automatically discarded and there's no need to manually clean them up.

But that virtue is a fault in JSF, because JSF is designed to have multiple requests applied against the same model/view set. It's called postback and request scope fails for postback, precisely because a different instance of request scope object is constructed from scratch for each postback. There's no ongoing conversational state.

This most commonly causes problems when using the datatable and selection JSF controls, but in your case, what has probably happened is that a request was constructed on a PersonBean, its "person" attribute was set, then a postback occurred and the original PersonBean object was destroyed, since a Request scope object has a lifetime of only 1 single request. The postback cause JSF to construct a new PersonBean instance, but that doesn't cause any state information (such as the "person" attribute value) to be initialized, since JSF knows nothing about that data - it was lost when the previous instance was destroyed.

So, to explain item #2 in detail, you've referenced a brand-new PersonBean instance whose "person" attribute was uninitialized (null), then attempted to obtain the "name" property from that (null) object, which leads to a NullPointerException.

How to fix? You need to give the PersonBean a longer lifespan. In JSF1, that would mean session or application scope - generally session scope. Session scope, however doesn't automatically clean itself up. In fact, there's no native JSF function to remove old session-scope objects. That can be annoying as your app tends to accumulate a lot of useless outdated objects. So JSF2 has something called "View Scope". View Scope is a special variant of Session Scope where JSF will detect when you navigate to a new View and automatically purge the old view's session objects in the same way that request scope objects get purged when they are no longer useful.

SO:



Note that I omitted the @Named annotation, since the default naming for JSF backing beans is the bean's classname with the first character folded to lower-case, and therefore matches your explict @Named value.

Session-scope (including ViewScoped) beans must be serializable or your webapp server may complain. Even though ViewScoped beans have a shortened lifespan, it's still long enough that the server needs to be able to page it to backing store and/or pass it to another cluster node.




Thank you sir for the response.

I have tried to change my annotation into @ViewScoped but when i still get no output and i when i tried to omit @Named annotation upon executing on show.xhtml my list had gone.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!