> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Juha Lindfors
> Sent: Wednesday, May 24, 2000 2:08 PM
> To: jBoss Developer
> Subject: RE: [jBoss-Dev] EJX GUI: jboss.xml AND ejb-jar.xml?
>
>
>
> 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)
>
almost the model (= logic in my mind) is the live ejb.ejx objects the file
is merely a persistent representation of the data these objects need.
marc
> 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
> >
> >
> >
>
>
>
