On Mon, 16 Apr 2001, Sam Newman wrote:
> > I think your thinking is flawed. Unless I misunderstand
> > you still and your not really thinking of trying to run
> > a non-servlet class in Tomcat...
>
> But a servlet can of course use a non-servlet class. I could imagine
> some kind of class required to setup a server for external access
> being run by tomcat. This class could be accessed outside of tomcat,
> and so wouldn't be a servlet. Esentially whilst you cannot directly
> access non-servlet classes, you can do it using a simple servlet
> wrapper.
Exactly. I have something set up that does something like this. The
servlet just acts as an "interface" to the non-servlet classes, which
are essentially the "application" and/or "business rules/logic", which
really don't belong in the servlet. (This was done before J2EE was
around, I'd do it differently now.) Remember, generally, servlets are
really just a way to access an application, not the application
itself. I don't think there is really a problem with having
non-servlet classes (when done properly) -- in fact, I've seen lots of
problems from people trying to put too much into servlets, things
would be cleaner if they separated some things into non-servlet
classes. This is a matter of your overall system design/architecture.
FWIW, to get back to what I think was the original question, I believe
there is something in the new (2.3) servlet spec that will address
loading/startup of non-servlet classes. At least, I remember that
being "on the list" some time back. The 2.3 spec (draft) is up at
java.sun.com, so you can check there.
Milt Epstein
Research Programmer
Software/Systems Development Group
Computing and Communications Services Office (CCSO)
University of Illinois at Urbana-Champaign (UIUC)
[EMAIL PROTECTED]