Sooo... we have:
the model, our beloved XML files
the view, our kick ass Swing dynamic tab sheet tree thingy
the control, which is da script language/the gui controls (combined
view+control)
Does that make sense to anyone else?
-- Juha
At 15:53 24.5.2000 -0400, you wrote:
>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
>
>
>
