Milt Epstein wrote: > First of all, I think you may be overreacting, we don't need such > attacks here. I wasn't attacking, I was defending. > > Second, to clarify, I think where people have the problem is not so > much with using the ServletContext and set/getAttribute to share > servlet resources, but the fact that the resources being shared are > servlets themselves. So, how is this different from servlet chaining or a request dispatcher include? > The thinking is that servlets are interfaces to the application, > handling the request/response end of things. Other objects, whose > main job is not related to the request/response processes and probably > represent part of another layer of the application, should be > implemented as different types of objects, and not as servlets. If > you do have it as part of a servlet, likely the design will be cleaner > if you abstract out that functionality into another object. Another > way of looking at it is that things that need to be shared by servlets > should probably not be servlets themselves. In most cases, I agree with you. However, there are some applications were it is appropriate to put complex biz logic in the servlet. I'm an advocate of single or simple servlet designs, but I don't limit my architectural arsenal to these designs. -ernie > On Tue, 22 Feb 2000, Ernie Varitimos wrote: > > > I disagree that accessing servlets through the servlet context is a > > flawed architecture. And you are wrong when you discount my > > assertion that the servlet context was not designed to group and/or > > share servlet resources. That is one of the principal reasons why it > > was created. > > > > There are of course, precautions that one should employ to guard > > against undesirable behaviors such as dynamic reloading. This can be > > managed using a number of techniques that I have iterated in other > > posts. In fact, I've created several high volume sites that use the > > servlet context to store references to sessions, object pools and > > other servlets, in single as well as multi-homed environments. It > > has proven to be effective, extensible and easy to maintain. > > > > I have yet to hear a reasonable, comprehensive explanation of why > > this is a flawed architecture and what are the superior > > alternatives. I know there are many alternatives, but I have not yet > > heard why this technique is inferior. There are several reasons why > > using the servlet context is perfectly acceptable in terms of reuse, > > collaboration and delegation (I find inheritance less desirable). I > > have also espoused out-of-the-box means of servlet collaboration, > > such as using the JSDT to distribute sessions and other objects > > across JVMs, or using reflection in concert with hidden html > > fields. But I digress. > > > > It's amazing to me that there are so many developers and some > > architects that live within the sandbox of knowledge they find in a > > few popular books or articles, as if these references represent the > > preferred ways of designing a servlet based architecture. Or they > > are so hung up on objectifying everything (OO elitists) at the > > expense of creating less readable and thus less maintainable code. > > > > > David Mossakowski wrote: > > > > > getAttribute() in ServletContext is to share objects across servlets. It does >allow > > > you to share the servlets themselves but that doesn't mean that this was the >reason > > > for this facility. It is a side effect. One way to disable putting servlets in > > > ServletContext is to have GenericServlet NOT extend Object, the other is to not > > > allow putting Objects in ServletContext. Let's not do either :-) > > > > > > I agree with others saying that if you need to call a method of one servlet from > > > another then your architecture is flawed. > > > > > > d. > > > Milt Epstein > Research Programmer > Software/Systems Development Group > Computing and Communications Services Office (CCSO) > University of Illinois at Urbana-Champaign (UIUC) > [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
begin:vcard n:Varitimos;Ernie tel;cell:781-929-3856 tel;home:781-784-1997 tel;work:781-784-3900 x-mozilla-html:TRUE url:http://www.skyserver.com org:Skyserver Consulting, Inc. adr:;;144 Upland Rd;Sharon;MA;02067; version:2.1 email;internet:[EMAIL PROTECTED] title:President fn:Ernie Varitimos end:vcard
