Mailing-List: contact avalon-phoenix-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon-Phoenix Developers List"
 <avalon-phoenix-dev@jakarta.apache.org>
Content-Type: text/plain;
  charset="iso-8859-1"
From: Peter Donald <peter@apache.org>
To: "Avalon-Phoenix Developers List" <avalon-phoenix-dev@jakarta.apache.org>
Subject: Re: [update][phyre] Management Console Status
Date: Thu, 1 Aug 2002 14:37:54 +1000
User-Agent: KMail/1.4.2
References: <200207291217.37863.proyal@apache.org>
 <200207311719.55017.proyal@apache.org>
In-Reply-To: <200207311719.55017.proyal@apache.org>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200208011437.54680.peter@apache.org>

Hi,

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

BUILD FAILED
file:/opt/projects/jakarta-avalon-apps/build.xml:204: Config descriptor:=20
/opt/projects/jakarta-avalon-apps/phyre/src/conf/phyre-config.xml does no=
t=20
exist.

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, h=
ost
> 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 con=
sist
> > of two roles, a "Navigation Bar" and multiple "Content Panels". Items=
 on
> > the "Navigation Bar" will load one of the Content Panels from the cur=
rent
> > container. This should allow proper separation of program data and GU=
I
> > functions and (hopefully) turn the app into more of a data (or at lea=
st)
> > 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-contai=
ner
> (say going from the root Phoenix container to the Container for a speci=
fic
> app), a Container can replace either one or both of the helpers to cont=
rol
> 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 roo=
t
> container.
>
> The containers are based around fortress at the moment. Each container
> should define a single navigation panel and multiple content panels. Th=
ere
> are two types of content panels support at the moment, a Grid display a=
nd
> 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 subcontain=
er,
> 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 wir=
e
> 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 mb=
ean.
>
>
>          -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 handl=
e
> that.
> -pete

--=20
Cheers,

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>