That was different issues: 1) Scripting is a way to modify an EXISTING DEFAULT JBoss instance by changing its settings. My proposal was going further than BSH by having a higher-level API to manage the server itself.
2) Categorization of the deployment directories: this is to make some cleanup 3) non hot-deployable folder that is still read at boot-time by the scanner: to allow wizard to create new persistent services and get synchronous feedback about the result of the deployment > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Scott M Stark > Sent: mercredi, 5. novembre 2003 01:32 > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Re: [jboss-group] RE: [Core] WG: > Comparison between BEA & JBoss > > Scripting is getting off of the original topic of not knowing how to > edit a component's config. Free form scripting as an admin tool > is a step backwards from an admin interface, and already exists via > the bsh deployer. > > Categorization of the deployment directories is also not > really addressing > the issue. We need a filtered view of the mbeans that loses the jmx > object names and replaces them with meaningful component names like > WebServer, WebApplication(/somectx), EJBContainer(jndiName=xxx), ... > > Bill Burke wrote: > > > What are we talking about here? > > > > Migration? > > Scripting? > > Management? > > > > What? > > > > Let's break it up into those categories and create separate > discussions. > > > > PLEASE CC JBOSS_DEV!!!!!!!!!!!!!!!!!!!! > > > > Bill > > > > Sacha Labourey wrote: > > > >>>> This is because you consider the system services as dirt. > >>> > >>> > >>> If you consider it > >>> > >>>> as the system, putting that in a system folder makes sense. > >>> > >>> > >>> Remember 2.4.x? > >>> > >>>> the deploy was empty and that was great from a user > point of view. > >>> > >>> > >>> Why? You're just moving the files to a different > location..? Now they're > >>> going to a system folder and trying to figure out which > file they should > >>> modify to get their SSL invoker configured...? > >>> > >>> Am I missing something? > >> > >> > >> > >> Yes and no. If you are considering the SSL invoker, then > yes, my examples > >> deeply sucks. Now, if you consider applications (EAR, JAR, > SARs), my > >> example > >> is ok. :) > >> > >> I was speaking about deploying new stuff, not modifying > existing one. > >> > >> Should we be able to deploy "scriptlets" that can modify > existing system > >> config (scripts � la Jetty) => instead of modifying a > system config you > >> deploy a new one that says: > >> currentServer().getServletEngine().getDefaultInvoker().setPort(38); > >> > >> This is somehow the VBA approach � la microsoft: you > expose an object > >> model > >> of your server and you let developers script it through > JavaScript, Java, > >> Python, etc. And the object model (i.e. API) is a wrapper > around real > >> objects which allows for more flexibility when making the server > >> evolve: you > >> code against a given API version, not a real set of objects whose > >> names may > >> change. > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
