This is very interesting.
I will do theory and applied.
Theory: In my days at SUN it struck me that sys-admins of large solaris
system always went around saying "say <verb> on <targetAdmin> with <values>
" to their co-workers who would in turn type it in at a command line (CL),
in turn some would say "DO a ...." etc etc.
The insight here is that administration is made of sentences and complete
actions. It became painfully obvious that GUI, clicking through menus and
choices can be a longer process if you know what you want to say or do and
can say so in a command line at once. "Talking" a full phrase AT ONCE is
sometimes easier than *building* that sentence by "clicking" through GUI
pull down menus, check boxes and options, before clicking "Apply-DONE".
(You have to know what you are doing though, this is in no-way gui bashing,
both are needed as another mail pointed out)
Practice: The fact is that the structure of all the information you
describe is held in the ejx.ejb objects held in RAM and are therefore
accesible from other means than the gui or built from file. There should be
direct access through the CommandLine that talks to a container, a bit like
you have a "shell" to the kernel, you would have a "shell" to the container.
In fact the gui and such is just to generate the XML file and we have to
redeploy to regenerate the ejx.ejb objects from the xml file. It is
entirely possible that we access these objects natively in memory/container
(they have all the getters and setters we need (thanks rickard ;-)) and just
redeploy the bean with the new "spoken" parameters (in a Command Line for
example) in fact it should in parallel update the XML file that holds the
persistence version of this information but we should go
commandLine -> memory -> redeploy from memory (-> in parallel update XML
file)
rather than
GUI -> file -> redeploy -> memory (new EJX objects) like ALL the industry
DOES
So it is clear that the GUI has its big uses but that sys-admin and trained
developers will find teh CL more "admin friendly" (Unix's big secret ;-) and
that we should work naturally from the EJX objects in memory... one more
reason to separate cleanly the GUI in EJX from the EJB object in information
holders in EJX.
<close the bible/>
Ok, Norbert Lataille has done such a Command Line interface in spyderMQ,
nothing very fancy, lives in a class, but can be made very powerful with the
Regexp (regular expression for Java from Jakarta) package as we could really
have a "proto-shell" for you to do some scripting of the XML files. IF you
don't like the command line, we could do that command line in the GUI.
Imagine: 24th century, aboard a probe, headset on, power sysadmin has gogles
on, is plugged into system, manages jBoss 23.4, interplanetary distribution
of resources flow system.
He speaks:"
SA: "open shell". Response: "hi"
SA: "connect to confMaster". Response: "confMaster online"
SA: "connect to container Abraham in Mars-Lander", R: "Abraham is online,
welcome, confMaster".
SA: "display EJX :) configuration of beans life-support" ...R: "Displaying"
(gui popup with information)
SA: "change pool size in bean life-support to 55". R: "Changing bean
life-support pool size to 55, soft redeploying"
SA: "Disconnect". R: "Abraham wishes you a good day, confMaster"
Of course stack traces in "verbose mode" would not play very well with this.
Sys administration is the key to the future web, not development.
marc
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Juha Lindfors
> Sent: Wednesday, May 24, 2000 1:46 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [jBoss-Dev] EJX GUI: jboss.xml AND ejb-jar.xml?
>
>
>
> Hey,
>
> At 15:00 24.5.2000 -0400, Dan wrote:
> >Worst-case scenario would probably be five or six for EJBs alone,
> >thinking off the top of my head: deployment descriptor, basic
> >container settings, advanced container settings, O/R mapping,
> >security configuration, and whatever else I missed. Of course, EJX
> >should probably be a J2EE tool, not an EJB tool, given the
> >ambitions of this project. So add some more to the list to
> >configure web settings, JMS settings, etc.
>
> Ok, I think even with a conservative estimation we could say
> we're facing a
> rather big configuration task. Potentially it can get huge.
>
> GUI alone won't cut it. What we need is scripting.
>
> Here's a scenario:
> We've got a J2EE server (which we will real soon now! :) with a couple of
> J2EE applications. Each has maybe dozen or more objects, some
> servlets, few
> stateless sessions, a bunch of entities.
>
> So let's say Jay the application assembler wants to do some fine tuning to
> the apps. He thinks hmm, lets try to increase some of the container pool
> sizes. Now he goes through a bunch of nodes on the tree, clicks
> the correct
> tab on each one, few clicks to up the pool size from 50 to 55, applies
> changes and ok's.
>
> Well that didn't work, the system performance went down the tubes. There
> was some magic limit between having a pool of 50 objects vs. 55. Now Jay's
> in a real hurry to fix this up again. So again he goes clicking
> through the
> gui (a major pain) to set the individual pool sizes for each
> container back
> to 50.
>
> Where instead he wants to say:
> Go and change all pool sizes that match this container
> description A to 50.
>
> Or:
> Change the O->R mapping of all entities that are packaged in
> foo.bar.* bean
> classes to map String to VARCHAR2(255)
>
> Or even:
> Change the descriptions of all beans that have ejb-refs to ejb/acme/*
> naming context, except the one that comes bean packaged as
> com.wombat.gimmick, and change their descriptions to say "This is an ACME
> gimmick".
>
>
> Now I think that's the kind of config power a system admin or app
> assembler
> will be glad to have. The GUI will be good to have too, of course, but I
> think to scale to the worst case scenario you described, we need something
> more than checkboxes, tabs, and trees.
>
> -- Juha
>
>
>
