Cameron McKenzie

Got to apache.org and look under portals. You'll se JetSpeed2 and Pluto.

Pluto is just a container that runs on Tomcat - it lets you test individual portlets, but isn't a comprehensive server - more of a testing engine.

JetSpeed2 is a JSR168 compliant portal server, with lots of bells and whistles.

My signature links have multimedia tutorials that demonstrate creating JSR168 portlets, and deploying them to JetSPeed2

Keep the questions coming!

-Cameron McKenzie

It'll be in the portlet-api.jar file.

It's there when you install pluto or jetspeed2.

You don't really have to 'get it' if your environment is set up properly.

-Cameron McKenzie

The second ISBN is the latest edition of the first book.

Many improvements have been made, with over 100 more pages over the original printing, more focussed content, and additional test questions.

So, it's really just different editions of the same thing. People also told me they hated the ExamScam name, so I got rid of it. Switched publishers as well for a more reliable suppy chain.

So buy away!

-Cameron McKenzie

I'd actually say that the SCJA covers far more than the SCJP exam. The SCJP exam is all sytax focussed, but it does indeed go more in depth on the syntax than SCJA.

SCJA is wide, but not very deep. SCJP is deep, but not very wide.

-Cameron McKenzie

I failed only two courses in my entire life.

The first was Turbo Pascal at Western University, and the second was Introduction to Computers at Durham College. That was about 10 years ago.

Right now, I have a very successful career in the computer industry.

Don't let set backs set you back. Use them to move forward.

-Cameron McKenzie

http://www.scja.com
http://www.pulpjava.com

You might be getting hung up on semantics too much.

Strictly speaking, a web server does not have a servlet engine or container. A web server handles http requests, and maps those requests to files. Requests for Servlets or JSP's are then directed to an application server such as Tomcat. Apache is a web server, and it does not contain a Servlet engine.

Portlets run in a portlet container. All the services of the portal server are provided to a portlet through the container. Without the container, a portlet could not run.

If you're quoting the spec, here's a snippet from the JSR286 specification (Portal 2.0)

A portlet container runs portlets and provides them with the required
runtime environment. A portlet container contains portlets and
manages their lifecycle. It also provides persistent storage for portlet
preferences. A portlet container receives requests from the portal to
execute requests on the portlets hosted by it.
A portlet container is not responsible for aggregating the content
produced by the portlets. It is the responsibility of the portal to handle
the aggregation.
A portal and a portlet container can be built together as a single
component of an application suite or as two separate components of a
portal application.

If a portal server runs portlets, it needs a portlet container. I guess, theoretically, you could have a portal server that doesn't run portlets, in which case, I guess it wouldn't need a portlet container. Of course, what good would a portal server be if it didn't run portlets?

-Cameron McKenzie
[ July 06, 2007: Message edited by: Cameron McKenzie ]

Portlets run within a portlet container. It's still there.

-Cameron

Windows service? Windows service? I spit on the windows service.

The windows service just kicks off the startup batch file. The windows service is good for starting off tiny, insignificant applications like Norton Anti-Virus, or Windows Messaging. But for real applications built by IBM, the windows service is a waste.

The windows service expects everythnig to start up in 10 seconds or something. If your app server has a 500 meg footprint, which is the minimum practially with WebSphere, then just filling that memeory will take longer than the service is willing to wait. As a result, you get a timeout error from the service, despite the fact that WebSphere is starting normally and properly.

Plus, the service only starts server1, which is useless when you go to a federated domain.

Do the startserver server1 thing from the DOS propmt, aka command prompt, and look for errors there.

From that point, if there are problems, look in the log files.

Here's a great link about troubleshooting WebSphere Application Server problems, including info on trace logs, system logs, error logs, activity logs, the service log, and the IBM Log Analyzer tool:

How to TroubleShoot WebSphere Application Server Errors and Problems

Good luck!

-Cameron McKenzie

The init parameters are set in the xml file, and as such, are read-only, but you can set normal read-write parameters at runtime. In fact, I usually do. It's a great scope, although a context can get out of sync across JVMs.

To put something in as soon as an application starts, you can use the appropriate context listener. That makes sure stuff is initialized before the first client request comes in.

-Cameron McKenzie

No what you are asking for is completely and totally impossible.

Essentially, you want a user to add a portlet to a page. When they click on a url in that portlet, the portlet then should remove itself from the page entirely, which is actually a portal administrative task, and then, add a new portlet, to the same page, in it's place. Then, when a url in this second portlet is clicked, the portlet removes itself entirely from the page, causing all sorts of administrative steps to happen in the background, and then the new portlet appears. Lets not even get into the fact that when a portlet is removed from a page, all of the PortletPreferences or PortletData information is completely removed. Essentially, you'd have to write your own portal server to make this type of thing possible.

However, maybe your portlet has two JSP pages. When a link in one JSP is clicked, the second appears. When a link in the second JSP is clicked, the first one appears. The flow is managed by the portlet class, which correctly would be acting as a controller. I think this would be easier than trying to completely re-engineer a portal server.

Okay, my response is fairly snide and tongue in cheek. The fact is, with a portlet, you have to shift your mind a bit and think differently. It isn't a JSP/Servlet application anymore. But don't overcomplicate things. Keep it simple.

And just to note, with a live portal, portlets are very, very, very rarely ever added or removed from a page. People tend to get comfortable with their portal, and tend not to change it.

I've got a bunch of tutorials on JSR168 portlet development at my website (Check out my signature links) Please check them out. They might help you get more comfortable thinking in a portlet mindset.

-Cameron McKenzie

John, John, John, where do we begin? Is this a live app, or just a proof of concept type scenario.

One thing that makes me a little nervous is asking a user to log in. One of the reasons for using the portal is the ease with which we can delegate the task of user management to the portal. You should use the portal to log the user in, taking advantage of the massive user management facilities provided through the portal. I believe the request object has a method that gives you the name the user used to log in.

Now for the idea of one portlet calling on another portlet. You're thinking in too much of a Struts/JSF/Servlet state of mind. This isn't really how portlets are supposed to work. I mean, you want the portlet the user used to magically disappear (I don't think that's possible), and then have two new portlets just add themselves to the same portal page, and display with information provided from the first portlet. I think you're going to have to redesign the portal to achieve this. It's not supposed to work that way.

I don't mean to be trite, but you really have to change your thinking when you move to the portal.

Here's what I might do, if you are totally committed to not using the portal user management facilities.

Create a portlet that logs the user on. Have three JSP pages: one is the landing page (index.jsp), the successful login page, success.jsp, and the loginfailed/request password page, loginfailed.jsp. When the portlet first displays, you display the landing page. If they log in successfully, you send the to the success page, and if login fails, you send them to the loginfailed.jsp page. That alleviates the need to have portlets displayed and removed from the page.

For some tutorials on portlet development with JSR168, check out my free tutorials: Free Multimedia Tutorials on Portlet Development

Please write back and tell me how this does or not fit into your current scenario.

-Cameron McKenzie

Classloaders just kill me. Cocoon, Struts, Ant....every technology I use seems to want something different from them.

If you're using WebSphere, and want a good description of how the WebSphere Classloaders work, you can check out the letsgetloaded link on my website.

www.technicalfacilitation.com

Here's a better one:

Understanding and Configuring WebSphere Classloaders: What is WebSphere?

-Cameron McKenzie

[ July 03, 2007: Message edited by: Cameron McKenzie ]
[ July 03, 2007: Message edited by: Cameron McKenzie ]