Hi Joe, you have covered the primary areas folks are faced with when trying to use WebSphere to write and run their servlets. I have found WebSphere's servlet engine seems to work pretty well too, but I am probably biased, ibm'er that I am. There is a definite learning curve with WebSphere that everyone will suffer thru, no doubt about it. WebSphere v3 is a whole different beast than v2, it is much richer in function as well as in complexity. The catch-22 is you will meet with frustration if you don't read the WebSphere doc. But without a working knowledge of the servlet API, JSPs, browser/webserver/appserver concepts, not a whole lot of it will stick on the first reading. I think you have to play around with WebSphere a while, then go back and reread it and it will make a lot more sense. Personally for me, it wasn't until I understood the steps of how an incoming URL from a browser got processed/mapped to the physical location of a servlet, jsp, html, gif, etc. in WebSphere, that I felt I had reached a major milestone. I would like to add some /*** commentary ***/ to your commentary - for the most part your observations are right on, but there are some clarifications to be made as well as amplifying what you have discovered. What I Learned on my Vacation Part I - WebSphere What can I say? WebSphere works. It works pretty darned well. Of course, it's not without its little pecadillos, but in general it's a pretty solid product. Specifically, though, I learned the following: 1. Components. There are really four basic components to web applications: HTML, servlets, JavaServer Pages and Java beans (the sort of generic term for all your other Java support classes). Each is handled slightly differently by WebSphere, but they're pretty straightforward once you get the hang of them. 1A. HTML. HTML access is controlled completely by the MAP and PASS directives of your HTTP configuration. I've also done some preliminary research on the use of ACLs (Access Control Lists), enough to figure out how to secure access. I'll talk about that a little later. /*** There are actually two options for controlling HTML access, and the key is whether the "file serving servlet" has been configured for the web application containing that the HTML page. If the containing web application does not have the file serving servlet configured, then the HTTP webserver is charge of serving the HTML page. If the file serving servlet is configured, then the HTTP webserver's plugin code will send the http request to the WebSphere's servlet engine, which in turn will locate the HTML page and return it back to the HTTP webserver. WebSphere "default" web application does not have the file serving servlet configured, so I am suspecting it was this web application that you have been working with. When the file serving servlet is configured, then the HTML pages must be placed alongside the JSPs in the web app's document root. (Only one document root is allowed per web app.) I think the primary tradeoff here is speed vs. organization: it is better performancewise to have the HTTP webserver serve static HTML than to send the request to an out-of-process servlet engine. But if you have a bunch of web app's, you can organize your HTML files into each web app's document root - it is better for your sanity. ***/ 1B. Servlets. The location of servlets are controlled by the CLASSPATH of your Web Application. This is defined in the "advanced" tab of your web application definition in the webadmin console. The web application definition is underneath the servlet engine definition, which is underneath the application server definition, which is under the node definition. /**** What is nice about the web app classpath is that it is reloadable. That is, if you update the servlet, the change will be picked up automatically. This is the default, which you can override. Or you can place the servlet class file in WebSphere system classpath, which is searched ahead of the web app classpath. If you do place your servlet in the system classpath, an update to that servlet classfile is not picked up automatically. This can be a source of frustration for those unaware of this distinction. A useful configuration option is to configure your servlet to "Load at Startup", where the servlet's init() method will be called when the Servlet Engine is started. Putting as much setup stuff in here can be useful, rather than waiting for the first time the servlet is invoked by a client. ***/ 1C. JavaServer Pages. I'm still a little fuzzy here. As close as I can determine, JavaServer Pages are handled by the web document root of the web application. I'm not sure what decides that a given URL is a JSP or a servlet request, but when a JSP is identified, the path portion of the URL is appended to the web document root to determine where the JSP is located. /*** Here is about as good a time as any to describe the URL mapping to the physical mapping. If this is understood relative to JSPs, then it is just a matter of applying it to the other types such as html, servlets, etc. Two key items in mapping an incoming URL is the web application's web path (e.g. "/webapp/examples") and the Servlet Web Path List of the jsp processor configured for that web application. For example, the jsp10 (JSP servlet) has a Servlet Web Path List of "/*.jsp", and when combined it forms: "default_host/webapp/examples/*.jsp". So a URL such as http://hostname/webapp/examples/myJSP.jsp gets mapped to the JSP servlet in the "examples" web app. Similarly, understanding how the "file" serving servlet and the "servlet invoker" get mapped is also worth noting. ****/ 1D. Beans. I've found that by far the easiest way to handle beans is to put them in a jar and put the jar in your application classpath. It's simple, and as long as your jar files are relatively small, there's no problem. When you upload a new jar file, WebSphere reloads it automatically. 1E. Overall. I put all my HTML, JSP, and servlets underneath my web document root. I use the PASS directive in my HTTP configuration to point the HTML to the appropriate directory. That way, all of my components, static or dynamic, are accessible in the same relative URL structure. /*** As mentioned earlier, it can be okay to do this but when developing more and more web applications, it can get a bit unwieldy. By defining the file serving servlet to web apps, you sacrifice some speed for the sake of organization, and you can place related html, gif, jsps, etc. all in one place. ***/ 2. Sessions. Sessions are an interesting concept. Most importantly, sessions are meant to be permanent; you're not supposed to go back and forth between a user session and an anonymous session. In fact, if you do, you lose your session variables. I've been using ACLs to secure my sessions, and they work quite well. Anyway, that's Part I of What I Learned on my Vacation. I'll be giving another update a little later in the week, I hope. Are there any particular areas anyone would like covered? +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: email@example.com +---
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.