ould roll
up PageCatalog and ServiceStatus, and be extensible. I've also wanted to
have a lightweight way of having services describe their internal state in
a semi-structured fashion.
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/Tapestry-app-live
s changing. Perhaps selected
services can listen for changes to some configuration object and act
appropriately?
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Tapestry-app-live-console-tp5714144p5714152.html
Sent from the Tapestry - User mailing list archive at
or 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 ;)
>
estry-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: us
I was wondering how people in the Tapestry community approach this and if
you have any tips on how to deal with this.
In the last couple of years, I've worked on a couple of Grails projects.
One very useful aspect of running a Grails app has been the Console plugin (
http://grails.org/plugin/cons
