geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: [DISCUSS] Reorg of Admin Console for 2.2
Date Mon, 24 Nov 2008 15:51:04 GMT
It would help me to see the fully populated proposal for the Navigation 
Tree side-by-side with the existing tree.  It seems one of your primary 
concerns here is the size of the tree and it isn't clear to me if this 
proposal is actually reducing the size of the tree.

I think the real fix for the size issue is to make the tree collapsible. 
  As you mention roles are the best way to eliminate the complexity for 
an individual user and permit filtering based upon a subset of of the 
roles for any particular user (server administrator, security 
administrator, cluster management, etc...).  Both of those will take a 
little longer to implement than a simple reorganization so we still need 
to consider what to do now.

More comments in-line


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)
Perhaps "Server Management" is a better title?  Services just doesn't 
seem descriptive to me.

>      - 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)
"Application Management" ?

>      - 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
Why is logging so special?  I think it's fine under Server Management.

>      - 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.)
I'm fine with keeping this a unique category since security is such a 
hot topic and we might eventually have a security administrator role 
someday.

> 
> 
> 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.
I agree that role/task organization is best.  For starters, we should 
rename leaf (task) in the tree with a task-like name.  For example, 
rather than "Web App WARS" it could be "Manage Web Applications (WARs)". 
   Organization of the tasks could be by role but it might make more 
sense by domain (Server tasks, Application tasks, Developer tasks, etc...).


> 
> 
> -Donald
> 
> 


Mime
View raw message