NEW!! FREE MOCK EXAM SIMULATORS FOR IBM PORTAL TEST 399 & IBM PORTLET CERTIFICATION EXAM TEST 829!!! Everything You Ever Wanted To Know About JSR-168 Portlet Development . . . PORTAL + TUTORIAL = www.portorials.com
Downloading and Installing the Right JRE for JetSpeed2 (JDK 1.5 - Java 5)
The place to get started on your portal development journey is at Sun Microsystem's website, by downloading JDK 5.0. This flash tutorial shows you how to download the JDK, which version you should be looking for on Sun's website, and it shows you what to expect during the installation. No code or compiling - just the installation.
Please support our site, link to us, buy some books, and remember:
Happy JetSpeed!
In my example, I downloaded and installed the JetSpeed-2
installation with the embedded Derby database. You can fine the
installation files here: Download
Jetspeed-2 Distribution
My tutorial was performed on a Dell Latitude Laptop with a P2
processor and 256 megs of RAM, so the installation requirements are
not overly onerous. For a listing of system requirements, look here:
JetSpeed
2 Installation Requirements
So, you want to develop portlets, eh?
Well, we should probably baseline this whole process with a little bit
of a discussion about just exactly what a portlet is. What is a portlet?
A portlet, in the most vulgar sense, is simply just a content delivery
vehicle. That?s what a portlet does ? it delivers content to a user.
Sure, a user can be as simple as a web page, or as voluptuous as a
handheld, multimedia device, but that?s what a portlet does ? it simply
delivers content to a user. Portlets are not web services; web services
are web services. Portlets are not web services. Portlets are not EJBs;
EJBs are EJBs. Portlets are not EJBs. Portlets are not JavaBeans;
JavaBeans are JavaBeans. Portlets are not JavaBeans. Portlets are simply
content delivery vehicles that render themselves within the confines of
a portal page. Partial-Page, Content Generation Note: the fact that
portlets are rendered within the confines of a portal page is not a
minor point. When a portlet renders itself, the content it delivers to
the user makes up only a portion of the total content delivered to the
end user. A portlet may make up a large portion of the total content
delivered to a user through a handheld device, or it may make up only a
quarter of the html page delivered to a client?s browser, but regardless
of how much of the content delivered to an end user for which a portlet
is responsible, the fact remains, that a portlet only generates part of
the total amount of content delivered to the end user. The Mighty
Portlet Interface From the standpoint of an application developer, a
portlet is any Java class that implements the javax.portlet.Portlet
interface. In many regards, a portlet behaves very much like a servlet
from the Servlet and JSP API. Like a servlet, a portlet is a shy little
creature that just sits on the hard drive, leaving everyone and every
other portlet to do their own thing. However, get a few drinks into a
portlet, and get it loaded, and that little portlet is loaded into
memory forever, and not unloaded until the portal server shuts down, or
the administrator explicitly takes the portlet out of service. Once
loaded, the single portlet instance can respond to an unlimited number
of client requests, bearing in mind, of course, the hardware limitations
of your portal server. Lifecycle Methods of the Portlet Interface The
javax.portlet.Portlet interface defines four lifecycle methods, with the
first two lifecycle methods being used to allow a developer to take
action when a portlet is loaded, or when a portlet is unloaded by the
portal server. Similar to the Servlet and JSP API, the method
corresponding to initialization is very uncreatively called
init(PortletConfig config), and the method that maps to the unloading of
a portlet is violently named destroy(). The very generic Portlet
interface also defines two more, very important, lifecycle methods,
namely the processAction method, which logically is intended to be used
during the action processing phase, and the render method, which as you
could imagine, corresponds to the phase where a portlet generates markup
that eventually gets displayed back to the client. The Abstract Class
GenericPortlet As a JSR-168, portlet developer, you will never create a
class that simply implements the Portlet interface. Okay, maybe never is
a little bit of an exaggeration, but when you code your portlets, you
don?t directly extend the Portlet interface, but extend the abstract
class GenericPortlet instead, which itself implements the
javax.portlet.Portlet interface. The GenericPortlet class provides
default implementations for the four important lifecycle methods defined
in the Portlet interface. GenericPortlet is the right class to extend
when you want to create your own, custom portlet. Along with providing a
do-nothing constructor, and an implementation of the four lifecycle
methods defined by the Portlet interface, the GenericPortlet class
defines the pivotally important do methods, namely doView,
doEdit, and doHelp. These methods correspond to the three standard
rendering modes of a portlet. The GenericPortlet also defines and
implements a doDispatch() method, which is always called before any of
the other do methods. Clever, a method named doDispatch is used to
dispatch requests to the appropriate do method. Portlets and the
Request-Response Cycle Okay, so far we?ve discussed what a portlet is.
In so doing, we have covered the mind numbing details of the Portlet
interface and the abstract GenericPortlet class. That describes what a
portlet is, but as developers, we are more concerned with what a portlet
does, and more to the point, how it does it. What Portlets Do? At the
most fundamental level, portlets are simply presentation components that
handle a request-response cycle. When a request comes in from a client,
portlets are responsible for inspecting that request, and figuring out
exactly what the client is requesting. Once the portlet has figured out
what the crazy client is requesting, the portlet must then figure out
how to respond. Before responding to a client, a portlet might use a
bunch of EJBs or JavaBeans, web services or JDBC, but eventually, a
response must be formulated and sent back to the portal for portal page
aggregation, after which, content is finally returned to the client. The
essence of portlet programming is handling the request-response cycle.
Conquer the request-response cycle, and the rest of the Portlet API will
easily fall under your control. Figure 1-1 The ancestry and the
implemented interfaces of a custom portlet. The Most Basic Portlet In
the most basic sense, a portlet simply handles a web based,
request-response cycle. As a Portlet developer, our fundamental
responsibility is to simply inspect the incoming request, and
subsequently supply an appropriate response back to the user. The
portlet API makes it very easy to develop delicious portlets that can
intelligently respond to this web based request-response cycle. To
create a portlet that can be viewed on any portal page, we simply create
a Java class that extends GenericPortlet, and code a special method
called doView. And what do we do in the doView method? We implement some
logic and eventually send some output to the client. The junk we output
appears within the confines of a portlet window, on a portal page.
Figure 1-2Output generated in the doView method is rendered within the
confines of a portlet, which appears, aggregated, on a portal page. The
HelloWorldPortlet is an example of a very simple portlet that extends
GenericPortlet, and simply outputs data to a client in the doView
method. In this example, when the portlet is displayed on a portal page,
the doView method is invoked, and the PortletResponse object is used to
both set the response type to text/html, and then deliver the ?Hello
World? message to the client. The PortletRequest and PortletResponse Two
supremely important objects are passed to a portlet?s doView method:
PortletRequest object, as the RenderRequest PortletResponse object, as
the RenderResponse Everything a developer wants to know about the
incoming request is stuffed inside the PortletRequest object. Anything a
developer wants to do to the client is done through the PortletResponse
object. Okay, to say anything can be done to the client might be a bit
of an exaggeration, as the developer can?t exactly slap an annoying end
user across the face with the PortletResponse object; but a developer
can send the end user an HTML snippet with some snide comment embedded
within it. Request-Response Programming Anything a developer wants to
know about the incoming request is bundled up inside of the
PortletRequest. Anything a developer is allowed to do to the client is
done through the PortletResponse object. Conquer the request and
response objects, and you?ve conquered portlet programming. Portlet
programming is just that simple. Of course, you don?t have to limit your
portlets to simple request-response handling. Few developers do. Java
programming is all about freedom, and you are free to make your portlets
as complex and crazy as you want. Fundamentally though, all portlet
development can be broken down to inspecting the incoming
PortletRequest, implementing some logic, and then using the
PortletResponse to deliver an appropriate reply back to the user. How
you leverage the various services provided to you through the J2EE
compliant application server that makes this whole portal thing
possible, is up to you. When it comes to portlet development, consider
yourself the curator of your own funeral. J Everyone Loves a Good WAR
Portlets don?t exist all on their own, in a peaceful little vacuum;
quite the contrary, as they actually exist, wrapped up within the
confines of a violent war file. As I have said before, in its most banal
form, a portlet is simply just a presentation layer component, and in
the Java world, the presentation layer is the domain of the Servlet and
JSP API. Portlets piggyback off the Servlet and JSP API in many ways,
and one of the ways they hitch a ride on the Servlet-train is in their
packaging. Both Servlet and Portlet applications are packaged and
deployed as Web Application aRchives, aka, WAR files. Like all war
files, a portlet war file contains a deployment descriptor named
web.xml. The web.xml file pays homage to the Servlet and JSP heritage of
the Portlet API, and is an important mechanism for describing how the
web container, which wraps around the portlet container in which a
portlet application runs, should manage a portlet application.
The Portlet Deployment Descriptor: portlet.xml Accompanied by the
required web.xml file, a portlet application deployment descriptor,
portlet.xml, also resides in the WEB-INF folder of a war file. The
WEB-INF folder branches directly off the root of the war. For the
HelloWorldPortlet coded in Figure 1-2, the corresponding portlet.xml
file would look like this: While both a servlet and a portlet WAR file
contain a web.xml file, what sets a portlet application apart from a
regular Servlet and JSP war file is the presence of a special deployment
descriptor named portlet.xml. For a portlet to truly exist, you must not
only code a class that implements the Portlet interface, but your
portlet must also be defined in the portlet.xml file. Conception and the
Portlet API The Java class that extends GenericPortlet, and subsequently
implements the Portlet interface, is like the sperm, whereas the
definition of the portlet in the portlet.xml file is like the egg. When
the two of them come together in the ovaries of the portal server, our
portlet truly comes to life. At the very least, the portlet.xml file
will define the portlet application, by providing a unique id. A
portlet.xml file will then define at least one, and potentially many,
portlets. A single portlet application maps directly to the single war
file that contains the portlet.xml file. Furthermore, the portlet
deployment descriptor will define each portlet contained within a given
war file, with the description including, at a minimum, a reference to
the underlying Java class, the markup language and modes the portlet
supports, and a title to be displayed above the portlet when it is
rendered by the portal server. The Remaining Elements of a WAR File So
far, we have established that a portlet application is packaged within a
war file, and a war file, at the bare minimum, contains compiled Java
code, along with a web.xml file, and a portlet.xml file, with those two
files being the deployment descriptors for the web module and the
portlet application, respectively. A war file will also contain a
special manifest file, creatively named Manifest.mf, in a directory
named meta-inf, which like the web-inf directory, sprouts out directly
off the root of the war file. The manifest file should be used for
maintaining the version of your applications. The contents of the
manifest file is usually just a version number: Manifest-Version: 1.0 If
you do not provide a manifest file of your own, the jar utility, or most
automated war creation tools, will create on for you. The Boring
Contents of the Manfest.mf File Manifest-Version: 1.0 What exactly is a
WAR File? Now I hate to break it to you, but a war file isn?t anything
special. A war file is simply a zip file, containing all of your portlet
related artifacts, all compressed inside of a single zip, with the
extension of the zip file changed to .war. That?s all a war file is. You
can actually change the extension of any war file to .zip, and it will
open up with any standard zip based utility. Of course, with Java being
Java, we can?t call a zip file a zip file ? everything in the Java world
has to have a cute and cuddly name, and nothing exemplifies the ideas of
cute and cuddly like a good, wholesome, war. Packaging Portlet
Applications So, a war file is really just a number of resources, zipped
up into a single file, with that zip file maintaining the special folder
structure needed for a portlet application. Along with the required
deployment descriptors, a war file will contain compiled Java code,
placed in a package aware structure in a subdirectory, off the root of
the war, named WEB-INF\classes. As it has been stated before, a portlet
application will also contain two deployment descriptors, named web.xml
and portlet.xml, both of which will be happily placed together in the
web-inf folder directly off the root of the war. Finally, all war files
will contain a rather mundane Manfiest.mf file in a directory named
meta-inf, which like the web-inf directory, will be found directly off
the root of the war. Figure 1-3 shows you how the HelloWorldPortlet
application, packaged in a file named mywar.war, would look like if you
inspected the contents with a WinZip utility. Figure 1-3 As you can see,
a war file can be opened up with WinZip, and the contents can be easily
discerned. A war file is just a zip file with a .war extension. Note the
folder locations of the compiled Java class, and the deployment
descriptors.
