avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: [update][phyre] Management Console Status
Date Thu, 01 Aug 2002 04:37:54 GMT

Could you give me a simple walkthrough on how to set this up. I tried to build 
a distribution but got a 

file:/opt/projects/jakarta-avalon-apps/build.xml:204: Config descriptor: 
/opt/projects/jakarta-avalon-apps/phyre/src/conf/phyre-config.xml does not 

I want to see all the swanky stuff that is a happening with this ;)

On Thu, 1 Aug 2002 07:19, Peter Royal wrote:
> On Monday 29 July 2002 12:17 pm, Peter Royal wrote:
> > What Works Now
> > --------------
> Same as before, except now everything isn't hardcoded! *phew* that was a
> nice exercise.
> I also added a shell script to run from the command line for *nix users,
> and a batch file for win32, but i can't test that one...
> You can pass in command line params to connect on startup, -h and -p, host
> and port respectively (port defaults to 1099 if not specified).
> > What The Future Holds
> > ---------------------
> >
> >  Now that things "kinda" work, I will be refactoring the application to
> > separate the GUI from the data (per the original thread referenced
> > above).
> >
> >  Each "level" of management will be a container. A container will consist
> > of two roles, a "Navigation Bar" and multiple "Content Panels". Items on
> > the "Navigation Bar" will load one of the Content Panels from the current
> > container. This should allow proper separation of program data and GUI
> > functions and (hopefully) turn the app into more of a data (or at least)
> > config-driver app.
> >
> >  The Context made available to the container will expose the ability to
> > set the current navigation panel and content panel.
> This is done.
> There are two "helpers" exposed to a Container. One to set a navigation
> panel and one to set a content panel. If a Container loads a sub-container
> (say going from the root Phoenix container to the Container for a specific
> app), a Container can replace either one or both of the helpers to control
> where the nav and content for the child container go.
> In practice, the Content helper is never replaced, but the Nav one is, in
> order to provide the "breadcrumb" trail of buttons to return to the root
> container.
> The containers are based around fortress at the moment. Each container
> should define a single navigation panel and multiple content panels. There
> are two types of content panels support at the moment, a Grid display and
> an MBean attribute / invoker panel (plus and custom panels, such as the
> configuration modification panel).
> I was thinking it would be neat for each block to be its own subcontainer,
> loading an xconf over JMX to define it and (perhaps, if this is a good
> idea..) loading the .class files for any custom panels over the JMX wire
> too.
> The way it is currently setup, each sub-container should be associated with
> an MBean. So for an app subcontainer, the Application MBean for the app is
> associated, and the attributes of that MBean are all made available in the
> context. What this means is that you can use the ${...} notation in the
> config for the subcontainer to substitute values from the associated mbean.
>          -o-
> What's Next!
> -------------
> Simple display of block attributes, then probably the loading of a
> sub-container for a block as mentioned above. After that will probably be
> logger config at the app level, but I need to see how logkit will handle
> that.
> -pete


Peter Donald
 Logic: The art of being wrong with confidence...

To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>

View raw message