You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Patrick Luby <pa...@sun.com> on 2001/10/18 00:29:46 UTC
[PATCH] Files to start implementation of an "Administrative Apps" webapp
in Tomcat 4.x
Hello to all,
In the following URL, there are functional specifications for an
"Administrative Apps" webapp.
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/catalina/funcspecs
Since I have not seen any work on implementing this, I implemented a login
screen to, hopefully, help get things started. I implemented the login
screen primarily because it is usually the first screen in most webapps.
In my implementation, I implemented the following things that I thought
other contributors to the webapp might find helpful:
- Internationalization using Struts property files. I've implemented both
English and Spanish property files. However, since Spanish is not
«mi primer idioma», any updates to my translations would be much
appreciated
- Integration with Struts 1.0. I have included a sample form with the
appropriate structs Action and Form java classes that can used as a
template for actual forms that do real work.
- Integration with Tomcat's Memory Realm security
- Conditional compiling if Struts 1.0 is not present. If not present, the
webapp will not be built at all. Since this webapp still requires a lot of
work, I thought that conditional compiling would be a good idea.
Attached are the following patches that implement this login screen. Can
someone commit them to the HEAD branch for me?
Attachment File to patch
---------- -------------
BUILDING.txt.patch BUILDING.txt
build.properties.sample.patch build.properties.sample
build.xml.patch webapps/build.xml
admin.tar.gz This creates the new webapps/admin directory
which needs to be "cvs added"
Thanks,
Patrick
Re: [PATCH] Files to start implementation of an "Administrative
Apps" webapp in Tomcat 4.x
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 23 Oct 2001 cmanolache@yahoo.com wrote:
> Date: Tue, 23 Oct 2001 12:49:46 -0700 (PDT)
> From: cmanolache@yahoo.com
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev@jakarta.apache.org
> 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
Re: [PATCH] Files to start implementation of an "Administrative
Apps" webapp in Tomcat 4.x
Posted by cm...@yahoo.com.
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.
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 !)
> > >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.
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.
Costin
Re: [PATCH] Files to start implementation of an "Administrative
Apps" webapp in Tomcat 4.x
Posted by "Craig R. McClanahan" <cr...@apache.org>.
(Following up on this a little late, but it's definitely worth
discussing).
On Wed, 17 Oct 2001 costinm@covalent.net wrote:
> Date: Wed, 17 Oct 2001 15:43:42 -0700 (PDT)
> From: costinm@covalent.net
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: [PATCH] Files to start implementation of an "Administrative
> Apps" webapp in Tomcat 4.x
>
> 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.
> >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.
> Costin
> (BTW, why doesn't somebody propose Patrick as a commiter ? )
>
Thanks to Christopher for taking care of that little detail.
Craig
Re: [PATCH] Files to start implementation of an "Administrative
Apps" webapp in Tomcat 4.x
Posted by co...@covalent.net.
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 ?
>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" :-)
Costin
(BTW, why doesn't somebody propose Patrick as a commiter ? )
On Wed, 17 Oct 2001, Patrick Luby wrote:
> Hello to all,
>
> In the following URL, there are functional specifications for an
> "Administrative Apps" webapp.
>
> http://jakarta.apache.org/tomcat/tomcat-4.0-doc/catalina/funcspecs
>
> Since I have not seen any work on implementing this, I implemented a login
> screen to, hopefully, help get things started. I implemented the login
> screen primarily because it is usually the first screen in most webapps.
>
> In my implementation, I implemented the following things that I thought
> other contributors to the webapp might find helpful:
>
> - Internationalization using Struts property files. I've implemented both
> English and Spanish property files. However, since Spanish is not
> «mi primer idioma», any updates to my translations would be much
> appreciated
> - Integration with Struts 1.0. I have included a sample form with the
> appropriate structs Action and Form java classes that can used as a
> template for actual forms that do real work.
> - Integration with Tomcat's Memory Realm security
> - Conditional compiling if Struts 1.0 is not present. If not present, the
> webapp will not be built at all. Since this webapp still requires a lot of
> work, I thought that conditional compiling would be a good idea.
>
> Attached are the following patches that implement this login screen. Can
> someone commit them to the HEAD branch for me?
>
> Attachment File to patch
> ---------- -------------
> BUILDING.txt.patch BUILDING.txt
> build.properties.sample.patch build.properties.sample
> build.xml.patch webapps/build.xml
> admin.tar.gz This creates the new webapps/admin directory
> which needs to be "cvs added"
>
> Thanks,
>
> Patrick