Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
Mime-Version: 1.0
Message-Id: <p05100302b766463688d1@[192.168.1.2]>
In-Reply-To: <Pine.LNX.4.33.0107020800510.21594-100000@costin.wyn.org>
References: <Pine.LNX.4.33.0107020800510.21594-100000@costin.wyn.org>
Date: Mon, 2 Jul 2001 11:39:34 -0400
To: tomcat-dev@jakarta.apache.org
From: Brad Cox <bcox@virtualschool.edu>
Subject: Re: tomcat gui
Cc: <cmanolache@yahoo.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 8:15 AM -0700 7/2/01, <cmanolache@yahoo.com> wrote:
>The "right" thing is to use a 2-layer architecture, with the backend
>beeing a set of servlets/jsps in /admin, with minimal ( or no ) GUI. The
>frontend can be a swing GUI, a webapp ( that can run on a different
>container and manage a set of tomcat instances ), or a module part of one
>of the existing admin GUIs.

Wouldn't this mean that the GUI would be ussless until the things 
tomcat depends on (apache to some extent (port 8080 conflicts), 
connectors, classloaders, jar files) are all exactly right?

In my experience, these are precisely the things that most often go 
wrong and generate the most obscure errors. By this reasoning, the 
GUI should concentrate on these things first and avoid relying on 
tomcat-based functionality until the fundamentals are known to be 
right.

PS: Building Java GUIs is straightforward given Visual Age or simlar. 
The hard part is understanding what tomcat needs to get on its feet 
and building this understanding into a GUI, either by implementing it 
independently or by catching and reporting exceptions thrown by 
existing tomcat code.
-- 
---
For industrial age goods there were checks and credit cards.
For everything else there is mybank.dom at http://virtualschool.edu/mybank
Brad Cox, PhD; bcox@virtualschool.edu 703 361 4751