You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Sandro Martini <sa...@gmail.com> on 2010/03/02 01:20:09 UTC

Console for Tomcat

Hi to all,
my name is Sandro Martini and I'm one of the Developers of Apache
Pivot ( http://pivot.apache.org/ ), a RIA Framework.
I cross-posted this to our developers list (here in CC) so other Pivot
developers can join the discussion.

My post here is to see if someone of Tomcat developers is interested
in supporting us making a Console for Tomcat, but instead of usual Web
pages, making it as a RIA Applet or an Application (for example
deployed via Web Start). Or at least if you think this could be an
interesting application for Tomcat.

I haven't looked (yet) at Tomcat sources, but I think that probably
the way Tomcat published data should be extended for our purposes, for
example we are able to read natively xml and also (better choice for
us) json formats. Maybe we could add a parameter in our queries asking
Tomcat for data published in one of those formats.
For security, we already support Basic authentication, and we have a
prototype for Digest authentication.

Some time ago I've seen an experimental feature like this for the
Glassfish 3, but with JavaFX as Client and exchanging data via REST.

In detail, I'm thinking on the following features, to see how things looks:
- Server Status (standard and also the Full version), a prototype
could start to implement this
- List Applications

There could be also the Tomcat Deployer in RIA version.

For a Full Administration Console (I don't see this since a long time)
we have to see later, this is complex and requires many features ...


Do you think the effort could be interesting also for the Tomcat community ?


I hope both projects can collaborate, to start creating a new
generation of Web Applications.


Thanks for the attention and best regards,
Sandro Martini

Fwd: Console for Tomcat

Posted by Sandro Martini <sa...@gmail.com>.
Hi to all,
I got no answer to my last post from Tomcat developers, BUT I've seen this:

https://issues.apache.org/jira/browse/COMDEV-23

and from what I've read (there and in some other mail on Tomcat
developers mailing list) seems that they are starting to improve
Tomcat for this goal, and this is very good.


So I think that we can start to see in more detail what to do, maybe
in a JIRA ticket, or other ... comments ?
And maybe start write something after the 1.4.1 release.


Bye,
Sandro

Re: Console for Tomcat

Posted by Sandro Martini <sa...@gmail.com>.
Hi,

I'm continuing the study to see what type of Graphical (RIA) Console
could be developed for Tomcat, and I have spoken with other Pivot
developers, but at this point we need some help from you to better
understand some key points that make that application really useful.

JMX could be the way to exchange data with Tomcat, but do you think
it's more useful a Monitoring (all at Runtime, no persistent changes)
via JMX, or a Configuration Application (and in this case we could
load/save config files directly if on the same host, or better calling
some service exposed by Tomcat and let it the load/save work) ? Or
both ?


> My first use case to try to address is some of most common operations, like:
Monitoring:
> - list/manage applications and maybe server status
> - deploy/undeploy/start/stop applications
Configuration:
> - list/manage users
> - list/manage datasources

That's why this was my first idea for some simple features to
implement, and this could be the beginning.
Then, as suggested, a step further could be the ability to handle a
Cluster of Tomcat, but here probably we'll need the support of someone
of you to avoid pitfalls.


Do you prefer to continue the discussion here or in other way (another
Tomcat mailing list, or other) ?

Comments are (very) welcome ...

Thanks again,
Sandro

Re: Console for Tomcat

Posted by Sandro Martini <sa...@gmail.com>.
Hi,

I'm continuing the study to see what type of Graphical (RIA) Console
could be developed for Tomcat, and I have spoken with other Pivot
developers, but at this point we need some help from you to better
understand some key points that make that application really useful.

JMX could be the way to exchange data with Tomcat, but do you think
it's more useful a Monitoring (all at Runtime, no persistent changes)
via JMX, or a Configuration Application (and in this case we could
load/save config files directly if on the same host, or better calling
some service exposed by Tomcat and let it the load/save work) ? Or
both ?


> My first use case to try to address is some of most common operations, like:
Monitoring:
> - list/manage applications and maybe server status
> - deploy/undeploy/start/stop applications
Configuration:
> - list/manage users
> - list/manage datasources

That's why this was my first idea for some simple features to
implement, and this could be the beginning.
Then, as suggested, a step further could be the ability to handle a
Cluster of Tomcat, but here probably we'll need the support of someone
of you to avoid pitfalls.


Do you prefer to continue the discussion here or in other way (another
Tomcat mailing list, or other) ?

Comments are (very) welcome ...

Thanks again,
Sandro

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Console for Tomcat

Posted by Sandro Martini <sa...@gmail.com>.
Hi to all, and thanks for your feedback, I've waited a little before
to respond to start to look better at some of the Tomcat JMX features.
I cross-post Pivot Developers here to give others some update.

> Costin
> There is a servlet that dumps all JMX objects - in a strange format ( like manifest or INI file - not hard to parse ).
> Would be great ( and quite easy ) to make it also output json.
> All information you want should be there - and much more. Exposing new data is also easy.
> You can also use some of the JMX access methods - RMI, etc.
thanks for the info, for us reading json data is well supported, but
we'll have to use jmx to set values I think.
In any case, this could be a starting point.

> Rainer
> Trying to aim at the middle ground might trigger more interest. Being able to remotely administer, but maybe not using a very high level configuration management. That's something one could also discuss on the users list.
I think this could be our right choice, thanks for the info.
> AFAIK one of the problematic parts of the old admin webapp was getting storeconfig into a working and maintainable state. In other words: how does one correctly save changes applied to a configuration by a console?
Pivot Applets / Applications (as a RIA) will run on Client, usually
downloaded from the Server (maybe with a new, dedicated Console webapp
of Tomcat), and some parts of it can also run inside the Server. We
can also use a local storage, but in this case probably we have to
call something on the server to make it (check, then) update config
files, and force a reload.

This discussion is very interesting for me, because you (Tomcat
Developers) know very well what is needed, and what is to be done, so
any info and suggestion is welcome. The idea to manage a Cluster of
Tomcat instances is very interesting, but my only fear is that could
be too much long for us. Also the idea of the json-jmx proxy is good.

My first use case to try to address is some of most common operations, like:
- list/manage applications and maybe server status
- deploy/undeploy/start/stop applications
- list/manage users
- list/manage datasources
- etc ...

You think these features could start to give some value or many others
are required ?


After this, the main problem we have at Pivot is that currently the
Developer Team is little, so starting with a long/complex project
could be a problem (we have a lot of features to implement in Pivot),
but doing something step by step could be a practical choice.


I expect that Greg Brown, the Pivot Team Leader can join here and
explain better its point of view.

Thanks to all,
Sandro

Re: Console for Tomcat

Posted by Sandro Martini <sa...@gmail.com>.
Hi to all, and thanks for your feedback, I've waited a little before
to respond to start to look better at some of the Tomcat JMX features.
I cross-post Pivot Developers here to give others some update.

> Costin
> There is a servlet that dumps all JMX objects - in a strange format ( like manifest or INI file - not hard to parse ).
> Would be great ( and quite easy ) to make it also output json.
> All information you want should be there - and much more. Exposing new data is also easy.
> You can also use some of the JMX access methods - RMI, etc.
thanks for the info, for us reading json data is well supported, but
we'll have to use jmx to set values I think.
In any case, this could be a starting point.

> Rainer
> Trying to aim at the middle ground might trigger more interest. Being able to remotely administer, but maybe not using a very high level configuration management. That's something one could also discuss on the users list.
I think this could be our right choice, thanks for the info.
> AFAIK one of the problematic parts of the old admin webapp was getting storeconfig into a working and maintainable state. In other words: how does one correctly save changes applied to a configuration by a console?
Pivot Applets / Applications (as a RIA) will run on Client, usually
downloaded from the Server (maybe with a new, dedicated Console webapp
of Tomcat), and some parts of it can also run inside the Server. We
can also use a local storage, but in this case probably we have to
call something on the server to make it (check, then) update config
files, and force a reload.

This discussion is very interesting for me, because you (Tomcat
Developers) know very well what is needed, and what is to be done, so
any info and suggestion is welcome. The idea to manage a Cluster of
Tomcat instances is very interesting, but my only fear is that could
be too much long for us. Also the idea of the json-jmx proxy is good.

My first use case to try to address is some of most common operations, like:
- list/manage applications and maybe server status
- deploy/undeploy/start/stop applications
- list/manage users
- list/manage datasources
- etc ...

You think these features could start to give some value or many others
are required ?


After this, the main problem we have at Pivot is that currently the
Developer Team is little, so starting with a long/complex project
could be a problem (we have a lot of features to implement in Pivot),
but doing something step by step could be a practical choice.


I expect that Greg Brown, the Pivot Team Leader can join here and
explain better its point of view.

Thanks to all,
Sandro

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Console for Tomcat

Posted by Rainer Jung <ra...@kippdata.de>.
On 03.03.2010 00:14, Bill Stoddard wrote:
> On 3/2/10 1:33 PM, William A. Rowe Jr. wrote:
>> On 3/2/2010 7:18 AM, Mark Thomas wrote:
>>> On 02/03/2010 00:20, Sandro Martini wrote:
>>>
>>>> For a Full Administration Console (I don't see this since a long time)
>>>> we have to see later, this is complex and requires many features ...
>>> This is the bit that, to me, offers an opportunity for real value.
>>>
>>>> Do you think the effort could be interesting also for the Tomcat
>>>> community ?
>>> Potentially. Something else to think about is handling multiple Tomcat
>>> instances. If you could manage tens of instances from a single client
>>> then that would get a lot of interest from the user community.
>> This was pretty much the description of the incubating Lokahi effort,
>> which
>> sadly was mothballed, for now, due to lack of interest from the developer
>> community.
>>
> Lokahi did not generate much interest from the user community...
> unfortunately.

As far as I understand Lokahi tried to manage both, the Apache Webserver 
and Apache Tomcat. Its goal was real enterprise type management, so e.g. 
it put all configuration data into a database. That's a huge step from 
were we are now (Tomcat manager webapp) and in the Lokahi domain the 
"user" community is typically operations people who are often relatively 
far from being a developer and contributing.

Trying to aim at the middle ground might trigger more interest. Being 
able to remotely administer, but maybe not using a very high level 
configuration management. That's something one could also discuss on the 
users list.

AFAIK one of the problematic parts of the old admin webapp was getting 
storeconfig into a working and maintainable state. In other words: how 
does one correctly save changes applied to a configuration by a console?

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Console for Tomcat

Posted by Bill Stoddard <wg...@gmail.com>.
On 3/2/10 1:33 PM, William A. Rowe Jr. wrote:
> On 3/2/2010 7:18 AM, Mark Thomas wrote:
>    
>> On 02/03/2010 00:20, Sandro Martini wrote:
>>
>>      
>>> For a Full Administration Console (I don't see this since a long time)
>>> we have to see later, this is complex and requires many features ...
>>>        
>> This is the bit that, to me, offers an opportunity for real value.
>>
>>      
>>> Do you think the effort could be interesting also for the Tomcat
>>> community ?
>>>        
>> Potentially. Something else to think about is handling multiple Tomcat
>> instances. If you could manage tens of instances from a single client
>> then that would get a lot of interest from the user community.
>>      
> This was pretty much the description of the incubating Lokahi effort, which
> sadly was mothballed, for now, due to lack of interest from the developer
> community.
>
>    
Lokahi did not generate much interest from the user community... 
unfortunately.

Bill


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Console for Tomcat

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/2/2010 7:18 AM, Mark Thomas wrote:
> On 02/03/2010 00:20, Sandro Martini wrote:
> 
>> For a Full Administration Console (I don't see this since a long time)
>> we have to see later, this is complex and requires many features ...
> 
> This is the bit that, to me, offers an opportunity for real value.
> 
>> Do you think the effort could be interesting also for the Tomcat
>> community ?
> 
> Potentially. Something else to think about is handling multiple Tomcat
> instances. If you could manage tens of instances from a single client
> then that would get a lot of interest from the user community.

This was pretty much the description of the incubating Lokahi effort, which
sadly was mothballed, for now, due to lack of interest from the developer
community.

Re: Console for Tomcat

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/2/2010 7:18 AM, Mark Thomas wrote:
> On 02/03/2010 00:20, Sandro Martini wrote:
> 
>> For a Full Administration Console (I don't see this since a long time)
>> we have to see later, this is complex and requires many features ...
> 
> This is the bit that, to me, offers an opportunity for real value.
> 
>> Do you think the effort could be interesting also for the Tomcat
>> community ?
> 
> Potentially. Something else to think about is handling multiple Tomcat
> instances. If you could manage tens of instances from a single client
> then that would get a lot of interest from the user community.

This was pretty much the description of the incubating Lokahi effort, which
sadly was mothballed, for now, due to lack of interest from the developer
community.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Console for Tomcat

Posted by Costin Manolache <co...@gmail.com>.
There is a servlet that dumps all JMX objects - in a strange format ( like
manifest or INI file - not hard to parse ).
Would be great ( and quite easy ) to make it also output json.

All information you want should be there - and much more. Exposing new data
is also easy.

You can also use some of the JMX access methods - RMI, etc.

Costin

On Tue, Mar 2, 2010 at 5:18 AM, Mark Thomas <ma...@apache.org> wrote:

> On 02/03/2010 00:20, Sandro Martini wrote:
>
>> My post here is to see if someone of Tomcat developers is interested
>> in supporting us making a Console for Tomcat, but instead of usual Web
>> pages, making it as a RIA Applet or an Application (for example
>> deployed via Web Start). Or at least if you think this could be an
>> interesting application for Tomcat.
>>
>
> I'm generally in favour of changes that make it easier for folks to
> customize and extend Tomcat. That said, I'd want to look at each specific
> change on its merits.
>
> As for an alternative manager implementation, I'm currently neutral. I'd be
> a lot more interested if a maintained replacement for the admin console
> (from Tomcat 5) was on the cards.
>
>
>  I haven't looked (yet) at Tomcat sources, but I think that probably
>> the way Tomcat published data should be extended for our purposes, for
>> example we are able to read natively xml and also (better choice for
>> us) json formats. Maybe we could add a parameter in our queries asking
>> Tomcat for data published in one of those formats.
>>
>
> Tomcat's internals are mostly designed to be accessed via JMX. If you can
> talk JMX then most of the work is done. There is a HTTP proxy to the JMX
> interface in the manager app. Maybe a json-JMX proxy?
>
>
>  In detail, I'm thinking on the following features, to see how things
>> looks:
>> - Server Status (standard and also the Full version), a prototype
>> could start to implement this
>> - List Applications
>>
>
> This should be trivial. If it isn't then, I'd have concerns about the
> overall viability of the approach.
>
>
>  There could be also the Tomcat Deployer in RIA version.
>>
>
> I'd view that feature as essential.
>
>
>  For a Full Administration Console (I don't see this since a long time)
>> we have to see later, this is complex and requires many features ...
>>
>
> This is the bit that, to me, offers an opportunity for real value.
>
>
>  Do you think the effort could be interesting also for the Tomcat community
>> ?
>>
>
> Potentially. Something else to think about is handling multiple Tomcat
> instances. If you could manage tens of instances from a single client then
> that would get a lot of interest from the user community.
>
> Mark
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Re: Console for Tomcat

Posted by Mark Thomas <ma...@apache.org>.
On 02/03/2010 00:20, Sandro Martini wrote:
> My post here is to see if someone of Tomcat developers is interested
> in supporting us making a Console for Tomcat, but instead of usual Web
> pages, making it as a RIA Applet or an Application (for example
> deployed via Web Start). Or at least if you think this could be an
> interesting application for Tomcat.

I'm generally in favour of changes that make it easier for folks to 
customize and extend Tomcat. That said, I'd want to look at each 
specific change on its merits.

As for an alternative manager implementation, I'm currently neutral. I'd 
be a lot more interested if a maintained replacement for the admin 
console (from Tomcat 5) was on the cards.

> I haven't looked (yet) at Tomcat sources, but I think that probably
> the way Tomcat published data should be extended for our purposes, for
> example we are able to read natively xml and also (better choice for
> us) json formats. Maybe we could add a parameter in our queries asking
> Tomcat for data published in one of those formats.

Tomcat's internals are mostly designed to be accessed via JMX. If you 
can talk JMX then most of the work is done. There is a HTTP proxy to the 
JMX interface in the manager app. Maybe a json-JMX proxy?

> In detail, I'm thinking on the following features, to see how things looks:
> - Server Status (standard and also the Full version), a prototype
> could start to implement this
> - List Applications

This should be trivial. If it isn't then, I'd have concerns about the 
overall viability of the approach.

> There could be also the Tomcat Deployer in RIA version.

I'd view that feature as essential.

> For a Full Administration Console (I don't see this since a long time)
> we have to see later, this is complex and requires many features ...

This is the bit that, to me, offers an opportunity for real value.

> Do you think the effort could be interesting also for the Tomcat community ?

Potentially. Something else to think about is handling multiple Tomcat 
instances. If you could manage tens of instances from a single client 
then that would get a lot of interest from the user community.

Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: Console for Tomcat

Posted by Mark Thomas <ma...@apache.org>.
On 02/03/2010 00:20, Sandro Martini wrote:
> My post here is to see if someone of Tomcat developers is interested
> in supporting us making a Console for Tomcat, but instead of usual Web
> pages, making it as a RIA Applet or an Application (for example
> deployed via Web Start). Or at least if you think this could be an
> interesting application for Tomcat.

I'm generally in favour of changes that make it easier for folks to 
customize and extend Tomcat. That said, I'd want to look at each 
specific change on its merits.

As for an alternative manager implementation, I'm currently neutral. I'd 
be a lot more interested if a maintained replacement for the admin 
console (from Tomcat 5) was on the cards.

> I haven't looked (yet) at Tomcat sources, but I think that probably
> the way Tomcat published data should be extended for our purposes, for
> example we are able to read natively xml and also (better choice for
> us) json formats. Maybe we could add a parameter in our queries asking
> Tomcat for data published in one of those formats.

Tomcat's internals are mostly designed to be accessed via JMX. If you 
can talk JMX then most of the work is done. There is a HTTP proxy to the 
JMX interface in the manager app. Maybe a json-JMX proxy?

> In detail, I'm thinking on the following features, to see how things looks:
> - Server Status (standard and also the Full version), a prototype
> could start to implement this
> - List Applications

This should be trivial. If it isn't then, I'd have concerns about the 
overall viability of the approach.

> There could be also the Tomcat Deployer in RIA version.

I'd view that feature as essential.

> For a Full Administration Console (I don't see this since a long time)
> we have to see later, this is complex and requires many features ...

This is the bit that, to me, offers an opportunity for real value.

> Do you think the effort could be interesting also for the Tomcat community ?

Potentially. Something else to think about is handling multiple Tomcat 
instances. If you could manage tens of instances from a single client 
then that would get a lot of interest from the user community.

Mark