If we are thinking of a deeper hierarchy, here is another (more destructive ^_^) proposal to entertain. I'm still kind of new here, so might have missed lots of background. Just trying to give my 2 cents from an "outsider"'s point of view.
+ Servers + Application Server - Geronimo Kernel (put Information, Java System Info, Thread Pool and Shutdown portlets in the same page here) - Web Server - JMS Server - System modules (Since they are "system", they should be part of the server) - Repository - New server assembly + Apache HTTP Server + Derby DB server + Applications - Deploy New (Suggest to merge in the plan creator, so that users can either choose to use an existing plan file, or create a new one using the wizard) - User applications (merge WAR, EAR and Client. I don't quite understand the reason to divide them) - Server plugins + Resources - DB pools - JMS resources - JEE Connectors + Security - (AS IS) + Monitoring and Troubleshotting - Monitoring - Logs - Debug Views -Jack 2008/11/25 Donald Woods <[EMAIL PROTECTED]> > Thanks for your response. My comments in-line below. > > -Donald > > > 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" > category. > > 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 <[EMAIL PROTECTED]> 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 >>> >>> >>> >>
