From: "Noel Peden" <[EMAIL PROTECTED]> Sent: Thursday, August 01, 2002 12:48 PM
> I'm pretty new to this .jsp/servlet arena, and now that I have to start > conversion of an old perl/cgi app I'm not quite sure how to structure it. > Here's my situation/question: > > I've got one db to connect to, need authentication / sessions, and need to > use .jsp's for layout. Concurrent access is not very likely, but I like to > be thorough and guard against it anyway. Is it better to use a javabean to > maintain a common db connection / session or to have a servlet handle all > requests and forward results to jsp? I haven't done either, so I don't know > their strengths or weaknesses. Any help would be appreciated. Clearly, we're not talking rocket science here for your app, but that doesn't make your app any less important. But the key is that there is certainly a lot of experience out there of things to do and not to do. The first thing I think you should do, is read the Servlet Spec 2.3. Read it at least twice, it's not long. As you read it, think how it applies to your application. What's important is to look at your app logically focused on the functionality, and not worry about how it "used" to be written. You mention authentication and sessions, both services that are provided in the Servlet Spec. They come "for free", so its wise to learn to leverage these facilities rather than "do it the old way". Servlets and JSPs are very flexible, but the concept of the Webapp and the WAR file tend to be a bit strict, and new users come in and try to lever their old app onto this architecture and have problems. Embrace the specification and the formats, and work within those guidelines, and you will have a lot less headache. If you start with these formats in mind up front, it's a lot easier than trying to squeeze your app into these formats later. Tomcat 4 is a nice choice as it is the reference implementation for the specification, so it can use that as its focus. Whereas another container may tempt you to using facilities that are not as portable. In many ways the Servlet 2.3 spec is the primary documentation for use with Tomcat. You may not care about portability now, but the app seems simple enough to where you might as well make it portable. It's a great relief when you encounter problems to know that your Appserver and Webserver are, essentially, disposable if something else can meet your needs better. Once you've gone through and have a good idea of what the container provides you, then you can look at how to break up your app using JSPs and Servlets or whatever. Lots of things over at jakarta.apache.org that can help you there (Struts is popular, Velocity can work if you don't want to use JSPs), etc. Look over the MVC (Model View Controller) paradigm and see if its something that you can work with. If you can avoid integrating with a Webserver (e.g. Apache or IIS), then for heavens sake DON'T. The configuration of getting the Webserver to work with the Appserver can be a great time sink. But if your system doesn't need it, don't waste your time. Most of the containers contain perfectly usable Webservers. Don't let this connection slow down your development if its not necessary. Anyway, the key thing is to start with the Servlet Spec and work from there. Today it's quite complete and offers a lot of functionality. If the spec doesn't say it can do something, then don't assume that you can. The only thing not directly covered in the Servlet Spec, is the DBConnection pooling. At this stage, that tends to be container specific, though the J2EE spec documents how things like Connection Pooling should be configured, and many containers are implementing that. Good Luck! Regards, Will Hartung ([EMAIL PROTECTED]) ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
