geronimo-scm mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Geronimo Wiki] Update of "Web Console" by AaronMulder
Date Sat, 16 Jul 2005 15:21:44 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Geronimo Wiki" for change notification.

The following page has been changed by AaronMulder:
http://wiki.apache.org/geronimo/Web_Console

------------------------------------------------------------------------------
- This page is meant to summarize my thoughts on what should go into a web console.  I've
looked at the donated web console, but haven't started digging into its construction yet.
+ This page is meant to summarize my thoughts on what should go into a web console.
  
  == Overall Structure ==
  
@@ -14, +14 @@

  
  Commercial consoles seem attracted to the tree view on the left.  The Applet-based navigation
trees have the advantage that they can receive notifications pushed from the server and update
themselves (which seems like it would require a bit of AJAX ninjitsu for a more static navigation
system).  Still, it's not clear how necessary that is, vs for example periodic refreshes.
  
- == Technologies ==
+ == Architecture & Technologies ==
  
  For a web-based console, portlets seem like a cool idea.  They may restrict navigation a
bit (for example; could your navigation system include an entry for each deployed application,
as opposed to only the category for applications?  not yet known), but it nicely segregates
components.
  
  Still, the appearance is kind of plain, and the console doesn't feel very dynamic.  It would
be cool to experiment with Laszlo a bit.  :)
  
  Ideally, we'll have a configuration API available.  Then we could build one or many front
ends against it.  For example, we may want a command-line tool that lets you change conflicting
network ports, using the same configuration API calls made by the web console.  I might want
to fool with Laszlo without rewriting the underpinnings of the portlet-based console.
+ 
+ Note that the current console does not have any separation between UI and configuration
API.  The Portlet classes load a kernel and start poking at it (setAttribute, listGBeans,
etc.).  They have some "renderer" classes that they delegate some work to, but they are also
tied to both portlets and Geronimo Kernel.  The JSPs are separate, for what it's worth, using
JSTL and Portlet taglibs.
+ 
+ Another issue with the current console is that it requires two separate web applications:
`/console` containing the Pluto code and page decoration and so on, and `/console-standard`
containing the actual portlets.  If you go to `/console-standard` directly, you get a variety
of unpleasant effects: a directory index including `META-INF/` and `WEB-INF/`, 500 errors,
blank pages, etc.  There's no security on `/console-standard`.  It would be nice if those
could be rolled into one and secured together, though I'm not sure how feasible that is.
  
  == Proposed Content ==
  
@@ -30, +34 @@

     * Basic Info (uptime, JVM, classpath, whatever)
     * Web settings (ports, threads, SSL, etc.)
     * EJB settings (ditto)
-    * J2CA settings (work managers, may just call this category "Thread Pools" if that's
what it is)
+    * J2CA settings (work managers, may just call this category "Thread Pools" if that's
all it is)
     * CORBA settings (ports, IOR settings, CSS/TSS, ???)
     * UDDI server (are there any pertinent settings?)
   * Services
     * Common Libraries (contents of repository, add/remove)
     * JDBC (add/edit connection pools, view statistics)
+      * Pool N
     * JMS (add/edit broker(s), connection factories, destinations, etc., view statistics)
+      * Broker M
+      * Destination N
     * J2CA (add/edit top-level connector deployments -- but is this different than apps/J2CA?)
+      * Connector N
     * Mail (basic defaults like SMTP server)
   * Applications (all below support deploy/start/stop/undeploy/redeploy, view configuration,
view statistics)
     * EARs (navigate to children)
+      * Application N
     * WARs
+      * Web App N
     * EJB JARs
+      * EJB JAR N
     * J2EE Connectors
+      * Connector N
     * Client Apps
+      * Client N
     * System Modules (everything that's not an app, connector, security realm, etc.)
+      * Configuration N
   * Security
     * Login Modules (if they end up getting independent configuration)
+      * Login Module N
     * Realms (groups of login modules, add/edit, view members, etc.)
+      * Realm N
     * SSL/Keystore (if it ends up being more widely used than in web apps)
  
  Some of these areas exist in the donated console, and others don't.  Few of the areas seems
as complete as I'd like them to be.  I actively dislike some, like the one that lets you drop
tables from the system database...
  
+ Anyway, there are few enough headers here that they could be represented as tabs along the
top, with sub-navigation (tabs or sidebar or whatever) for the 2nd level components.
+ 
+ I haven't thought how to represent a data source deployed as part of an EJB JAR deployed
as part of an application.
+ 

Mime
View raw message