You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Peter Royal <pr...@apache.org> on 2002/07/31 23:19:55 UTC
[update][phyre] Management Console Status
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 royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [update][phyre] Management Console Status
Posted by Peter Royal <pr...@apache.org>.
On Thursday 01 August 2002 12:37 am, Peter Donald wrote:
> Could you give me a simple walkthrough on how to set this up. I tried to
> build a distribution but got a
>
> BUILD FAILED
> file:/opt/projects/jakarta-avalon-apps/build.xml:204: Config descriptor:
> /opt/projects/jakarta-avalon-apps/phyre/src/conf/phyre-config.xml does not
> exist.
>
> I want to see all the swanky stuff that is a happening with this ;)
'ant dist' isn't doesn't work yet :)
just do 'ant' and use the shell script. The plan is to generate a SAR with a
mini-webserver that will let you launch phyre via java webstart.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [update][phyre] Management Console Status
Posted by Peter Royal <pr...@apache.org>.
On Thursday 01 August 2002 11:23 pm, Peter Donald wrote:
> > > What version of MX4J are you using?
> >
> > pass
> > -Djava.naming.factory.initial=com.sun.jndi.rmi.registry.RegistryContextFa
> >ct ory
> >
> > when starting phoenix.
>
> What do you think of setting this property inside the MX4JSystemManager so
> that don't have to set it on command line?
done.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [update][phyre] Management Console Status
Posted by Peter Royal <pr...@apache.org>.
On Thursday 01 August 2002 11:23 pm, Peter Donald wrote:
> > pass
> > -Djava.naming.factory.initial=com.sun.jndi.rmi.registry.RegistryContextFa
> >ct ory
> >
> > when starting phoenix.
>
> What do you think of setting this property inside the MX4JSystemManager so
> that don't have to set it on command line?
No problem, I make that change later today. I was just following the path of
least resistance to getting it all going :)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [update][phyre] Management Console Status
Posted by Peter Donald <pe...@apache.org>.
On Fri, 2 Aug 2002 11:30, Peter Royal wrote:
> On Thursday 01 August 2002 09:26 pm, Peter Donald wrote:
> > okay. Now I fell stupid. I Can't even get phoenix to start up using MX4Js
> > RMI server (I had always used old RMI interface for this stuff). I get an
> > unable to locate InitialContext error. So what exactly do I do to get
> > phoenix going?
> >
> > What version of MX4J are you using?
>
> pass
> -Djava.naming.factory.initial=com.sun.jndi.rmi.registry.RegistryContextFact
>ory
>
> when starting phoenix.
What do you think of setting this property inside the MX4JSystemManager so
that don't have to set it on command line?
--
Cheers,
Peter Donald
"Artists can color the sky red because they know it's blue. Those of us who
aren't artists must color things the way they really are or people might
think we're stupid." -- Jules Feiffer
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [update][phyre] Management Console Status
Posted by Peter Royal <pr...@apache.org>.
On Thursday 01 August 2002 09:26 pm, Peter Donald wrote:
> okay. Now I fell stupid. I Can't even get phoenix to start up using MX4Js
> RMI server (I had always used old RMI interface for this stuff). I get an
> unable to locate InitialContext error. So what exactly do I do to get
> phoenix going?
>
> What version of MX4J are you using?
pass
-Djava.naming.factory.initial=com.sun.jndi.rmi.registry.RegistryContextFactory
when starting phoenix.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [update][phyre] Management Console Status
Posted by Peter Donald <pe...@apache.org>.
On Fri, 2 Aug 2002 07:16, Peter Royal wrote:
> On Thursday 01 August 2002 12:37 am, Peter Donald wrote:
> > Could you give me a simple walkthrough on how to set this up. I tried to
> > build a distribution but got a
> >
> > BUILD FAILED
> > file:/opt/projects/jakarta-avalon-apps/build.xml:204: Config descriptor:
> > /opt/projects/jakarta-avalon-apps/phyre/src/conf/phyre-config.xml does
> > not exist.
> >
> > I want to see all the swanky stuff that is a happening with this ;)
okay. Now I fell stupid. I Can't even get phoenix to start up using MX4Js RMI
server (I had always used old RMI interface for this stuff). I get an unable
to locate InitialContext error. So what exactly do I do to get phoenix going?
What version of MX4J are you using?
--
Cheers,
Peter Donald
---------------------------------------------------
Murphy's law - "Anything that can go wrong, will."
(Actually, this is Finagle's law, which in itself
shows that Finagle was right.)
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [update][phyre] Management Console Status
Posted by Peter Royal <pr...@apache.org>.
On Thursday 01 August 2002 12:37 am, Peter Donald wrote:
> Could you give me a simple walkthrough on how to set this up. I tried to
> build a distribution but got a
>
> BUILD FAILED
> file:/opt/projects/jakarta-avalon-apps/build.xml:204: Config descriptor:
> /opt/projects/jakarta-avalon-apps/phyre/src/conf/phyre-config.xml does not
> exist.
>
> I want to see all the swanky stuff that is a happening with this ;)
Don't do a dist just yet, I still need to add javadocs. Doing a simple 'ant'
will now generate a SAR that you can throw into phoenix though. You do need
to setup the bits for signing all the jars that Web Start will deliver, and I
included a URL to a simple tutorial on doing so in the ant.properties.sample.
I needed to sign the jars vs running in the samdbox because the Excalibur
Source Resolver tries to read the user.dir property on startup, the thread
pools set context class loaders, and other fun things i didn't feel like
hacking around.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [update][phyre] Management Console Status
Posted by Peter Donald <pe...@apache.org>.
Hi,
Could you give me a simple walkthrough on how to set this up. I tried to build
a distribution but got a
BUILD FAILED
file:/opt/projects/jakarta-avalon-apps/build.xml:204: Config descriptor:
/opt/projects/jakarta-avalon-apps/phyre/src/conf/phyre-config.xml does not
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, 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
--
Cheers,
Peter Donald
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>