I think you're better off doing things in two different places. The
reason is that the POJO and the JSP serve different purposes. The POJO
reflects the data. The JSP reflects the display. It's usually a bad idea
to mix business logic with display logic. Google the term "MVC" to learn
more.

I've thought of several ways to do this, and I have to agree with
Chris on this one.
You're data layer, business layer, and presentation layer shouldn't
have to figure anything out from each other.

I know it seems like more work to add "address" to the database table,
AND the java bean, AND the JSP, but imagine this situation:

You have a NiftyLibrary that will update your JSP and database tables
based on any changes you make to your  POJO.

Now, NiftyLibrary is pretty complex, relying on reflection and other
"interesting" features.  Adding new features to NiftyLibrary is likely
to be a difficult process that requires regression testing, and still
uncaught bugs.  But that shouldn't matter, because its all automatic,
and you only want to change your JSP and database when your POJO
changes...

So, you add a new property to your POJO:
Address myAddress;

NiftyLibrary does its job and you have everything done already.

Then, your manager comes along and says. "Oh, on this specific page,
when these conditions are met, we want the Address to only display the
Street name and City".

What would have been a simple change in a JSP, is now a week long
project to update NiftLibrary to take that special case.

Trust me on this, I've done it both ways.