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/29 18:17:37 UTC
[phyre] Management Console Status
As the observant (and subscribed to avalon-cvs) members may have noticed, I
checked in a first, very-rough, cut of a swing management console for
phoenix. It is available at
http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-apps/phyre/
I have followed the general GUI patterns layed out by Peter Donald in the
following message:
http://marc.theaimsgroup.com/?l=avalon-dev&m=100666024311393&w=2
I believe his ideas in there hold true and will be roughly following them.
-o-
What Works Now
--------------
First, you need to be using the MX4JSystemManager in phoenix, and pass in the
"enable-rmi-adaptor" configuration option with a value of true.
You can then run phyre. Currently, it will attempt to connect to
rmi://localhost:1099 upon startup, mainly to make my life easy during
development. There is a File->Connect menu option available to connect to an
alternate host/port.
When it starts you will see a *VERY UGLY* looking screen. The two buttons at
the bottom to restart phoenix work, if you feel so inclined.
You can also click on "Hosted Applications" to see a list of applications
currently running inside of phoenix. If you double-click on an entry in the
grid you will drop down one context level and be modifying that application.
On the main application info screen the buttons for Stop and Restart work. If
an app is stopped you don't get a start button though :)
You can then click "Configuration" to see a list of the blocks and whether or
not there is currently any configuration information for them. If you
double-click on a block that has configuration information, you will get a
testbox with the XML representation of that Configuration.
If you have schemas for your blocks and are using a ConfigurationValidator,
you can hit "Validate" and validate your configuration.
Otherwise you can modify the configuration and hit "Update" and the
configuration will be stored in the ConfigurationRepository.
If you are using the FileSystemPersistentConfigurationRepository, when you
modify the configuration via the GUI, the changes between your active
configuration and the configuration that was stored in the SAR are persisted
to disk, and will be used next time Phoenix is started up.
-o-
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 what I will be working on next (ie when I finish this email and eat
lunch).
For forms, I am looking at the Luxor XUL package
(http://luxor-xul.sourceforge.net/index.html).
It looks really neat, but it is GPL licensed. Is that okay to use from an
Apache-licensed project if we are only using the binaries, not making
modifications to the Luxor source? One of the things I want to do is enable
the creation of a config modification screen for blocks but base it off the
schema. Since the schema will (most likely) be an XML document, if forms can
be represented as XML, I can write an XSLT to write forms from a schema! I
hate reinventing the wheel.
The other choice is Xybris
(http://www.jbrix.org/kits/xybrix/updates/2002-03-17.html) but it doesn't
appear to be under very active development. It is MIT licensed though which
(may) be more compatible with the APL.
back to work!
-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>
[update][phyre] Management Console Status
Posted by Peter Royal <pr...@apache.org>.
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>