Right - exposing the configurable values via JMX could work for the "configuration" aspect of such a console. I haven't worked w/ JMX enough, but it sounds like a lot of complication to add on top of the existing configuration system via symbols (e.g. it seems that I would need to add a jmx property for each configuration point that I might want to be able to read/write). In Grails, there already is a Configuration object, and you can get it in the console and read/write to it in exactly the same way that you would if you were configuring the application at build time (e.g. editing one of the *Config.groovy scripts). In Tapestry, is there a central place that I can possibly override in certain modes where this console is enabled that I can inject "overriding" configuration values into ?
About scripting - that's what I was thinking too : have the scripting language interpreter w/ a couple of key entry points defined to be able to look up services (e.g. I really don't care about injecting components or pages) that I would then be able to use in a script. The same approach would be useful even in a command line console ( I think a Tapestry based Scala app that I played with had the ability to start a command line console like that out of the box). The final question remains about being able to "override" things in the Tapestry "application context" on the fly . Is there a mechanism in the APIs exposed via Tapestry IOC, where after the application is started I can override particular services w/ alternative implementations ? In Grails, Groovy itself provided a lot of "shoot yourself in the foot" kind of flexibility where you could even override core JDK functionality (e.g. don't like the time returned by Calendar.getInstance() ?? no problem , just mess w/ the Calendar metaclass to override the static getInstance method). I'm not looking for that level of flexibility, but being able to override services within the app would be useful. Cheers, Alex K On Thu, Jun 28, 2012 at 7:36 AM, Lance Java <lance.j...@googlemail.com>wrote: > This sounds a bit like JMX, would publishing your services to JMX and > editing > via the JMX console solve your problems? > > If you'd still like to have the full power of a scripting language (eg bsh) > at your fingertips, you could @Inject the ObjectLocator and make it > available in the bsh context. From there you will be able to lookup any > service and invoke methods on them. > > > http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/ioc/ObjectLocator.html > > As you mentioned, this is a pretty large security hole ;) > > -- > View this message in context: > http://tapestry.1045711.n5.nabble.com/Tapestry-app-live-console-tp5714144p5714146.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
