On Thu, 24 Feb 2000, Ernie Varitimos wrote:
> 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.
You were defending for a while, then you were attacking :-). (You know
what they say, the best defense is a good offense :-).
> > 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?
My understanding is that servlet chaining is not part of any spec
partly because it is somewhat problematic, and the request dispatcher
is the new officially sanctioned, safer way of communicating with
other servlets. It doesn't rely on the servlets being in any
particular state, and doesn't use a "back door"/internal approach to
communicate with them the way your suggestion does.
> > 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.
You may be right, but if I ever ran into a situation where there was
complex biz logic in a servlet and/or I felt the need to instantiate
and pass around a servlet, I'd think long and hard about the design to
see if there's a cleaner way of doing it.
> > 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
>
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
