I've spent a reasonable amount of my career as a DBA and doing production
support. I'll tell right now that if you can do the GUI AND then provide a
script for configuration manipulation you are solving a HUGE category of
operational concerns for any significant scale environment!
+1E20
Andy Lewis
VERITAS Software, Heathrow, Florida
Voice: 407-531-7584 - Fax: 407-531-7686 - Cell: 407-718-4718
Pager: [EMAIL PROTECTED] - EMail: [EMAIL PROTECTED]
"The heights of genius are only measurable by the depths of stupidity."
-----Original Message-----
From: Juha Lindfors [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 24, 2000 4: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
