geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
Subject Re: [DISCUSS] Reorg of Admin Console for 2.2
Date Mon, 24 Nov 2008 21:02:53 GMT
Thanks for your response.  My comments in-line below.


Lin Sun wrote:
> Hi,
> Thanks for bringing this up to discussion.   I am not seeing the
> obvious advantage of what you propose and I have the following
> specific comments -
> 1. I kinda like what we currently have, Server and Service.

The current grouping makes no sense, as everything under Services is 
part of the "Server" and everything under Server is "services" the 
runtime is providing....

> 2. I think we should have a plugin category (if we are going to have
> the collapsible tree structure) and put the 3 plugin related portlets
> there (install plugin, export plugin and customer server assembly).
> Otherwise, I think it is better to have all 3 in one page (I believe
> we discussed this before on dev list).

Plugins should be viewed as just another application archive type, 
whereas exporting plugins and creating custom server assemblies has 
nothing to do with managing what applications are deployed in the 
current server runtime being managed, but are tools for those users who 
don't want to build plugins or custom assemblies via the maven c-m-p.

> 3. I really don't like the Tools name, as it is not concrete.   I'd
> rather see stuff organized into specific names instead of a generic
> name.

Then suggest another name/grouping.  The current "Debug Views" is 
misleading to admins, as it makes them seem as developer focused 
portlets, whereas they are really there for admins and developers.  We 
also have monitoring tools, which really should be performed by an 
external application for true production environments (and we need to 
include some pre-canned "health monitoring" templates out of the box for 
developers and simple environments.)  The Apache HTTP portlet has 
nothing to do with the provided Geronimo runtimes, as we don't include 
the Apache HTTP server.

The thought here, is to group all the portlets that are not used for 
server, application or security management, into a separate "tools" 

> 4. I like plan creator under Applications better, as it is today.

It provides no application management function today (aka. 
deploy/redeploy/undeploy) and is really only there because we didn't 
want to tie users to Eclipse (which we now have Deployment Plan Editors 
in the Eclipse tooling, so these should be viewed as optional tools now.)

> Maybe we should not rush the organization of the console navigation in
> 2.2, given that we are planning it soon.  I 'd rather to see us do it
> in one shot, instead of changing it in 2.2 and changing it again in
> 3.0.

This is a discussion to see what people think.  If the consensus is to 
wait another year or more for console improvements, then fine, but just 
because we're planning on cutting the 2.2 branch mid-Dec. shouldn't keep 
us from making improvements now.

> Lin
> On Fri, Nov 21, 2008 at 2:36 PM, Donald Woods <> wrote:
>> Given our Console navigation tree has gotten so large and many "new"
>> portlets were added in 2.0/2.1 without doing a proper reorg of what we had,
>> I'm proposing the following changes as part of GERONIMO-4423, 4424, 4425 and
>> yet to be created JIRAs:
>> 1) Reorg the Server Console contents into main categories of:
>>   - Services (config/resources)
>>     - combination of existing Server and Services portlets
>>     - contains portlets for server/service configuration
>>        info, threads, connectors, modules, jms server/resourecs, ...
>>     - future portlet to setup clustering/farming member servers
>>        and view their status would go here
>>   - Applications (app deployment and life-cycle)
>>     - portlets to deploy/redeploy/undeploy apps/wars/ears/jars
>>     - portlets to install/uninstall and stop/start modules
>>     - porlet to install plugins (not export or server assembly)
>>     - future updates and/or new portlet to support deploy/undeploy
>>        apps to clusters/farming would go here
>>   - Security
>>     - portlets focused on users/groups, keys/ca, realms
>>   - Logging
>>     - portlets to configure logging and log levels
>>     - separate pages for Server, Web Access and Derby log viewers
>>   - Tools
>>     - everything in current "Debug Views" category
>>     - Plan Creator portlet
>>     - Monitoring portlet
>>     - Embedded DB portlets (renamed to Derby * to reflect true usage)
>>     - Apache HTTP portlet (for creating mod_jk configs)
>>     - Exporting plugins
>>     - Custom server assemblies
>> I could see the Logging portlets as one page under Tools, as those are
>> really runtime tools (changes don't survive a restart) for debugging
>> server/application problems.
>> I could also see the Security portlets being split between the Services and
>> Tools categories (but really think these deserve their own category.)
>> The point, is that we need to review how the admin console is laid out and
>> try to regroup into Java EE roles/tasks/concepts, like server
>> config/resources, app deployment/mgmt and other tools/tasks.
>> -Donald

View raw message