Tapestry app live console

[Alex Kotchnev <ak...@gmail.com>]

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/console), which basically allows you to have a
"live"  console in your running application. In other words, you can
navigate to a particular URL and you can run scripts against your running
application - whether it's to inspect the state of the application from
within, or it is to manipulate the application (e.g. the approach was made
very useful for migration scripts that work better from the application
domain). Another aspect has been being able to put together ad-hoc reports
(as in, dump a bunch of data to a csv file).  Yet another useful aspect has
been to be able to configure/override application behavior "on the fly",
when there is no opportunity to do an immediate deployment - e.g.
overriding values for configuration keys

Is there an equivalent solution in the Tapestry world ? For running
scripts, it seems that adding a page with an input text area an an area for
the output that would interpret the input as some scripting language (e.g.
Beanshell, js, Groovy, Scala)  and make some tapestry infrastructure
accessible within the interpreter (e.g. being able to look up services by
class or name) should be able to accomplish most of this. In terms of being
able to "reconfigure" the Tapestry application "on the fly" - if there is
access to the Tapestry APIs, can I for example "override" a service just
like would be able to do if I were contributing to the AppModule ? How
about configuration - since a lot of it happens by dealing with Symbol-s,
can those be "overridden" on the fly ?

Granted, such a feature could be a huge security issue as it could allow a
user to run arbitrary code within the application, but I'll leave that to
the side. Let's assume that it is well secured.

I would appreciate any tips / ideas on the subject.

Cheers - Alex K

Re: Tapestry app live console

[Howard Lewis Ship <hl...@gmail.com>]

On Thu, Jun 28, 2012 at 5:29 AM, Lance Java <la...@googlemail.com>wrote:

> Tapestry IOC configuration happens once, when the app is started. It
> determines the symbols, constructs services and wires them all together.
> After that, Tapestry IOC's job is done and all of the services are acting
> upon the config they were provided during construction after that.
>
> If you want to change values at runtime, it will be via custom events on
> your services. Changing symbols will have no effect as each service has
> done
> it's own custom thing with the symbol (for example connecting to a database
> or writing a file etc).
>
> I think you need to think about exactly what is changing. Perhaps selected
> services can listen for changes to some configuration object and act
> appropriately?
>
>
Tapestry has tended to make design decisions that enforced stability,
predictability, and performance over runtime flexibility.  Although I can
see the desire to change configuration on-the-fly, this complicates the
implementation of services, as they go from having a simple singleton
lifecycle to something more complicated and aware of state changes to
configuration.

For Tapestry internals, especially, I prefer my services to have no mutable
internal state (wherever possible); that is, all fields final, storing
immutable values.  This isn't always practical; some services have mutable
caches of useful data and there's an overhead cost to maintaining that
(and, in development mode, clearing it when the external world changes).

That being said, I've long wanted to have a Dashboard page that could
present information about different parts of the running application, and
perhaps allow it to be modified or otherwise interacted.  This would 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-console-tp5714144p5714152.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>


-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

Re: Tapestry app live console

[Lance Java <la...@googlemail.com>]

Tapestry IOC configuration happens once, when the app is started. It
determines the symbols, constructs services and wires them all together.
After that, Tapestry IOC's job is done and all of the services are acting
upon the config they were provided during construction after that.

If you want to change values at runtime, it will be via custom events on
your services. Changing symbols will have no effect as each service has done
it's own custom thing with the symbol (for example connecting to a database
or writing a file etc).

I think you need to think about exactly what is 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 Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Tapestry app live console

[Alex Kotchnev <ak...@gmail.com>]

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 <la...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

Re: Tapestry app live console

[Lance Java <la...@googlemail.com>]

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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org