On Tue, 23 Oct 2001 [EMAIL PROTECTED] wrote:
> Date: Tue, 23 Oct 2001 12:49:46 -0700 (PDT)
> From: [EMAIL PROTECTED]
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: [PATCH] Files to start implementation of an "Administrative
> Apps" webapp in Tomcat 4.x
>
> On Tue, 23 Oct 2001, Craig R. McClanahan wrote:
>
> > > Given the complexity of the app and the fact that it has many external
> > > deps ( including JMX, etc), wouldn't be a better idea to create a separate
> > > repository, in the style of jakarta-tomcat-jasper and
> > > jakarta-tomcat-connector ?
> > >
> >
> > Historically, the admin UI for each version of Tomcat has lived with the
> > sources of that version. Because the details are so initmately dependent
> > on the internals of that particular server version, it makes sense to me
> > that we continue the convention in this case as well.
>
> Again, my point was that the proposed architecture is pretty complex. All
> historic admin UIs were minimal, with no external dependencies, and
> indeed very dependent on the internals of a paticular server version.
>
> Regarding external dependencies, I would be -1 on starting an app based on
> JMX as long as we don't have a clear answer from the PMC/ASF regarding the
> policy on binary licences. I love JMX, and I would be happy if ASF allows
> any redistributable jar to be used ( or at least decide on a number of
> licences that are allowed, or anything else ). But I would like to see a
> mail from the PMC or ASF clarifying this.
>
This would have to be an ASF board-level decision. So far, its being
discussed but there hasn't been a formal statement yet.
In the meantime, there is movement within Sun towards getting the JMX
license terms to be identical to the other Sun JAR files (jndi.jar and so
on), as well as eliminate the need to register in order to download it.
This has already been done, AFAIK, for ldap.jar which was the only other
exception.
> Regarding dependencies - the idea of JMX is to separate the
> instrumentation ( which is indeed very dependent of each container ) from
> the agent and management application. I don't think the agent and
> management application should be specific to tomcat, and given the
> complexity it should be in a separated sub-project ( or even project !)
>
In theory, JMX definitely makes it possible to create a completely generic
management tool, because the interface to the actual internal objects is
nicely abstracted. In practice, it's really tough to create a rich user
experience if the tool doesn't understand the relationships between the
managed objects (usually encoded in the JMX object name) so that it can
depict them in a manner that is understandable to the user.
The best we could do, is to essentially create a framework for building
admin tools, with a way to plug in the details. That is certainly
possible, but its a fair amount of work.
<Wearing-Sun-Hat>
My job responsibility over the next few months includes creation of the
Web Services Pack, which was announced last JavaOne, and which will
include Tomcat. For this pack, I need a nice UI for Tomcat 4 stand-alone,
and into which you can plug additional modules for configuring the extra
things that will be included in the pack.
I would *much* rather see this tool developed in the usual open
source way, rather than having to develop it in house. I've got some
people resources lined up to help build it. However, like most for-pay
projects, this one comes with deadlines and requirements of its own.
I have time to build a nice tool for Tomcat that Sun can use as the basis
of its own. But I don't have time to build a "be-all end-all fully
generic management tool" -- and I don't have the inclination, either,
because that's not the itch I'm trying to scratch.
</Wearing-Sun-Hat>
>
> > > >From that URL it seems the app will use:
> > > - JMX
> > > - Soap
> > > - Struts
> > > - RMI
> > > - ???
> > >
> > > While having an admin interface would be great, discussing and agreeing on
> > > the overal architecture would be even better - it seems a bit too heavy (
> > > at least for my taste ). ( "simpler is better" :-)
> > >
> >
> > The functional specs were posted quite a long time ago and got zero
> > comment -- IMHO the best way to get opinions is to follow your example and
> > just commit some code :-). That way, people can take a look, kick the
> > tires, and take a look around.
>
> Well, zero comment is a comment :-)
>
> This seems quite a big thing - and discussing and agreeing on the goals,
> technology and design is quite important.
>
> I'm +1 on adding a JMX layer ( assuming the licence problem is resolved ).
> How we do that - it's a different question, I think model mbeans would be
> a good idea (compared with adding another 20..30 interfaces, if simple
> MBeans are to be used ). ( everything that is configurable will have to have a MBean
> in the second case ). I also thing the exposed model should be
> independent of the internal implementation.
>
Check out the "modeler" package in jakarta-commons-sandbox -- it creates
Model MBeans for you based on an XML description of the attributes and
operations to be exposed, without having to create MBean implementations
at all (unless you need to add some additional functionality beyond just
calling the methods on the managed components). That's what I'm going to
propose that we use inside the server part. And it will certainly not
care what the front end admin tool is.
> For the rest ( management console, struts/soap, etc ) - I think it
> shouldn't be a tomcat-specific thing, and tomcat should be neutral to the
> management application.
>
Making a completely generic but still user friendly tool is hard. Making
a tool that embeds a small amount of knowledge about the objects it is
managing, but is easy to extend for additional (sets of) managed objects
is a still a bunch of work, but is much more feasible. I propose we do
the latter.
Given that, it's not all that big a deal to me whether it's done inside
the "jakarta-tomcat-4.0" repository, or in a separate
"jakarta-tomcat-admin" repository. But I don't have the time or the
inclination to build a server-neutral tool. Maybe someone else will want
to do that.
Does any other Tomcat developer have optinions or preferences on the
issues Costin is raising (not that I'm trying to shut him up -- just
inviting more input :-)?
> Costin
>
>
>
>
Craig
