Moving on, using a managed bean

So let's try using what is known as JSF managed beans.  Managed beans are plain old Java objects (POJO) that get managed by the JSF controller.

How it technically works is that the JSF library will scan the classes in your project for the @ManagedBean annotation.  When it finds a class, it registers it as a managed type.

Once registered, you can create beans all over the place in your JSF pages.  Beans can have one of six scopes:

• @RequestScope - This means the bean is created for the life of the HTTP request.  Once the HTTP request has been fully processed the bean is destroyed.  Basically, these beans exist so long as the request for a web page lasts.  Once the page has been serviced, the bean is no longer available.  This also applies to AJAX requests.
• @SessionScope - This bean is created for the life of the HTTP session.  Once a HTTP session is started, the JSF library will create this bean and allow it to last so long as the HTTP session is still open.  Once the HTTP session ends, due to inactivity or closing the web page, the bean is destroyed.
• @ViewScope - This is an interesting bean that will last through requests, so long as the current view has not changed.  This is useful is you present a single view to the user and then do a lot of AJAX in the background to modify that view.
• @ApplicationScope - This is a bean that is created as soon as the application is started.  That means as soon as you publish it to the server or upon the first HTTP packet to the application (this is dictated by the eager=true flag, setting to true is as soon as you publish it.)  Only use this kind of bean for things that can safely be shared between instances of sessions.  Just FYI, don't assume that this automatically means thread safety.
• @NoneScope - This is a bean that is created as soon as it is requested in a JSF page and destroyed as soon as it was created.  If you use the bean three times in your JSF page, then the bean is created and destroyed three times.  In my example to follow, the none scope would have sufficed.  Use this kind of bean for one shot stuff that doesn't need to be remembered, or if you intend on using this bean within another bean.
• @CustomScope - This is exactly what it says.  You define when and where the bean exists and get destroyed by modifying a Map that is created for managing this bean.  When you add an entry to the Map, the bean is created, when you remove the entry the bean is destroyed.  Use this when nothing above seems to fit your use-case.

So let's create a bean!

Right mouse click on your project and select New » Other…

This screen appears

 Choose the JSF Managed Bean and click Next >

We're just going to go with the defaults here with a little bit of extra like package name, generally you are going to name this something actually useful.

Fill in the information about your bean and I'm going to set it to request scope.  The package will be lan.testing.  You can also add a little description to the bean.  No idea where this description gets saved at the moment.  Go ahead and click finish.

Now you will have a newly minted request bean.

New JSF Managed Bean

Now at the moment this bean does absolutely nothing other than suck memory.  So let's make it do something more interesting.  Let's add a field in the Java class called message.  We will make this field private.  So let's add that now.  While we are at it, let's set the fields default value by placing that in the constructor.

Adding a field to the bean

Now let's expose that bean so that it can be used on our pages.  We do that by creating standard getters and setters.  Just press Alt+Insert in the IDE to get a popup.

Select the Getter and Setter… option

Check the boxes of the fields you want to expose, since we have one, we are exposing them all.

Your Java class should look like the following:

Your field is now exposed by the bean.

Now that we have exposed the field, let's go ahead and add that to our JSF page.  To access JSF managed beans we need to replace the static text in our tag with #{}.  The pound sign and curly brackets indicate to the JSF libraries that it needs to look at all of the registered classes.

Once we type that into the value you'll notice a code completion pop-up appear.

Code completions is happening.

In the completion box you should see the name of your managed bean.  Go ahead and select it.  It will now appear as #{whateverYouNamedYourBean}.

Go ahead and type period to get the next bit, this will show you what has been exposed by this bean.

Our field exposed by the bean

Go ahead and select the exposed message field.

Our completed code

Once you have done that, go ahead and press the giant play button to see the results.

Ta-da!  Your field in the Java class is now exposed and being used by the JSF libraries.  Right now, not very useful, but good to know that it is working.  All of this on Tomcat!

Quick point:
Beans are meant to allow you to create useful components to be used in your JSF application.  Right now it might be a bit hard to see that, but eventually you'll start building beans that are for all kinds of purposes, with all kinds of different scopes.

The thing to remember about beans is that you should take the million little cogs approach with them.  As opposed to building one giant bean or one huge session bean and one huge request bean, beans should be for a specific purpose in your web application.  You may have one that hold the current user's profile information, another to hold the current conversation that they are in, and so on.

Right now we are only using the read function (get) of the bean.  I'll show you next how to write (set) to the bean and explain a bit about why it works.

First JSF web application on Tomcat 7

Okay as promised, here is the first Netbeans 7.3 + JSF 2.1 + Tomcat 7 web application.

First download Netbeans, if you haven't already.  Go ahead and select the full all out, no hold bars download.  Next install the software and make sure you install the Tomcat that is included with Netbeans installer.

Okay now that you have all of that out of the way, go ahead and start up Netbeans and head over to the services tab and start up the Tomcat Server installed on your system.

Starting up the Tomcat server.  Netbeans 7.3 automatically detects this installed if you did it with the installer from the web.

Now go ahead and start a new project.  Choose Java Web | Web Application.  See the following images for the wizard screenshots.

Step 1 - Title your new web application.

Step 2 - Choose the server to deploy to and the context to use.  MAKE SURE YOU SELECT THE TOMCAT INSTALL!

Step 3 - Include what libraries you might need.  Make sure you click the JavaServer Faces library.  Tomcat doesn't come with JSF built in, you must manually add it!

Okay you should now have a shell project with the default index file.

Behold!  The default index file!

So to ensure that we are running JSF and not that the server is doing some sort of pseudo translation here, let's use an actual JSF tag.

I'll use the tag which does exactly what it says, it outputs text.  Here I'll just use some static value for the value attribute.

Adding in a JSF tag, don't forget the
tag.

Now go ahead and click on the run project icon, it's that giant play button up there.  If your Tomcat server is running (you better go catch it, ha ha) then it will deploy the project to the server and open up your browser to the context that you provided.

Pushing the Play button.

Ta-da!  Our project runs!

 So there you go, your very first JSF 2.1 application on a Tomcat server.

Here's some highlights.  Tomcat 7 does not come with JSF baked in.  It is a simple servlet server.  Ergo, you must include the JSF library with your project.  The nice thing is that Netbeans will go ahead and do that for you, because it knows that Tomcat doesn't have these libraries by default.

Draw your attention to the highlighted area.

Now here's the deal.  If at some point down the road, you add these libraries to the Tomcat server itself, then you need to make sure that Netbeans doesn't try to "help" you out here.  To do that, you need to indicate that the libraries do not need to be pushed to the server with the application.  Right mouse click on the libraries icon and choose properties.

If you do not see Properties, then it's because you aren't right clicking in the correct 16x16 space.

Once you do that this window appears:

Notice the check boxes highlighted.  When they are checked, that means the library will be "packaged" with the application.  If the libraries are already on the server, you don't need to package them.

Disclaimer:
Don't include the JSF libraries inside your server, just package them with the application.  Once you toss the libraries into the server, that pretty much makes that server a JSF Tomcat server.

The downside of this is, this could potentially ruin any old JSP applications that you have on the server.  Now it shouldn't but I would count on something jacked up happening the second you toss JSF libraries on a Tomcat running JSP applications.

I'll start covering some more fun stuff with JSF next post!  Have fun!

Loss of data and moving on.

Of course,

I've lost the whole project that I was doing in JSP and Tomcat.  I really don't feel like going back and going over the whole things…again.

So I'm going to need a new project now.  Hmmm…

Okay, let's do the good old fashion Tomcat 7 + JSF 2.0 + NetBeans IDE.

Not to say that I don't like Eclipse, but I'm a bigger fan of NetBeans.  Sorry for all of the Eclipse fan boys out there.  If it helps, I use Eclipse everyday with Android stuff.

In fact!  How about something Android?  That sounds like fun too!  So here's what I'm going to do going forward.

Monday and Friday I'll do a post about JSF and pretty much J2EE stuff.

Wednesday I'll do something about Android.  Why the hate for Android?  Because I spend so much time developing Android stuff for work, I get tired of even looking at the IDE.  I guess that's why my interest in the JSP thing waned so much.

I'm so capricious it's not even funny.  I'll setup some labels.  We will name the J2EE stuff with the J2EE label and when it includes TomCat, I'll add in TomCat.  When it deals with Glassfish I'll add Glassfish.  For the Android stuff, I'll just add the label Android.

Okay, so there we go.  Something to do.  Oh look it's Friday!  Better start working on my first J2EE post.

Cheers!