You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@esme.apache.org by Vassil Dichev <vd...@apache.org> on 2009/07/05 14:45:24 UTC
Scala interpreter action
Hello everyone,
There is now an action which interprets the text of a message as Scala
code and returns back the result. Here's how it works and some things
you can do with it.
First of all, you need to enable this feature. You will be able to
create "scala" actions even if it's disabled, but they won't do
anything. To turn it on, use this setting in e.g. default.props (the
only one you can rely on in a ):
actions.scala_interpreter.enable=true
*Note*: It's sensible to have this feature off by default, as you will
gain full control of the JVM in the classloader context of the
application. Unless there are security manager restrictions, you might
be able to execute OS code, shut down the JVM, modify the database,
inspect live objects and possibly change them, etc. This could be both
a threat and an advantage.
Now it's time to set up our embedded scala interpreter:
1. Create a pool, let's call it e.g. "scalapool"
2. Create an action, which has a filter for the newly created pool. In
our example, the filter is "pool:scalapool". The action itself is just
"scala". In theory, you could use any filter, but the special symbols
necessary for hashtags and users interfere with Scala code. Besides,
except for a pool, you don't have much control what gets in your
timeline, and I doubt that any unintended message there is valid Scala
code.
3. Send some Scala code to scalapool.
Let's see what we can do with Scala in ESME:
* Calculator
Try these:
- arithmetic calculations:
3 + 3
- string operations:
"olleH" reverse
-operate on lists, e.g. sum numbers:
List(1,2,3,4,5).foldLeft(0)(_+_)
As we can see, the result is displayed in a new message, which is a
reply to the current one, and is in the same pool. The message source
is "scala".
Printing to the console won't do what you expect (you won't see it in
your reply), so don't use it.
* Background execution.
Each new message is executed in a separate interpreter. While this has
some disadvantages (you lose the bindings for each consecutive
execution), there are some advantages to this approach. For instance,
you could have several computations execute in parallel, and the
previous won't block the next one. Try these messages, one right after
the other:
{Thread.sleep(10000); "later"}
"now"
The first message will wait for 10 seconds and then return the string
"later". If during those 10 seconds you manage to enter the second
message "now", the result will be returned before the result of the
first message.
This, of course, is an expensive way to schedule reminder messages. If
you want it, request a feature in Jira :)
* Monitoring
-free memory in the JVM:
Runtime.getRuntime.freeMemory
-total JVM memory:
Runtime.getRuntime.totalMemory
-current date and timezone on the system:
new java.util.Date
-get a JVM property, e.g. the JVM version:
System.getProperty("java.vm.version")
It would be very interesting how this runs in Stax. I tried to use
code which works in restricted environments (e.g. I read about
problems with classloaders in OSGi). As a whole, I think a sandboxed
environment like this is ideal for running ESME with the embedded
Scala interpreter, as it offsets the security implications somewhat.
As with all powerful features, I would think twice before enabling it
in a corporate environment where lots of important messages are
stored. On the other hand, I wouldn't hesitate to use it as a training
tool in a class where students are able to execute their Scala
assignments and the teacher can observe in real time how everyone is
doing.
So, what do you think? Is this something you find useful? Is there
something I missed?
Have fun,
Vassil
P.S. This is another mail in a growing list, which will (hopefully
soon) find its way to the wiki documentation or on the blog.
Re: Scala interpreter action
Posted by Richard Hirsch <hi...@gmail.com>.
I did 2 deployments today with both options for the scala interpreter.
I've just redeployed the one where it is turned off.
If anyone wants to test with it activated, just send me mail and I'll
use the other deployment
D.
On Mon, Jul 6, 2009 at 4:08 PM, David
Pollak<fe...@gmail.com> wrote:
> On Mon, Jul 6, 2009 at 1:43 AM, Richard Hirsch <hi...@gmail.com>wrote:
>
>> Should I deploy with this functionality active or not?
>
>
> I wouldn't. It's kinda like taping a "Hack Me" sticker onto the site. :-)
>
>
>>
>>
>> I just did a stax deplyoment with the
>> actions.scala_interpreter.enable=false
>>
>> D.
>>
>> On Mon, Jul 6, 2009 at 10:24 AM, Vassil Dichev<vd...@apache.org> wrote:
>> >> Should we remove it completely from the source or should we just
>> >> deactivate it by default?
>> >>
>> >> I agree that I wouldn't activate it in a producticve setting but it
>> >> might be useful while developing.
>> >
>> > Granted, this might not be the best way to monitor/debug ESME (e.g. if
>> > memory is so tight the JVM won't be able to create a new interpreter
>> > instance or send a new message). When I implemented the feature I was
>> > actually thinking of Dick's request for making it easier for ESME
>> > newcomers to learn Scala. I've also spent some time thinking about
>> > using ESME in a university and this feature makes a lot of sense in a
>> > classroom.
>> >
>> > My point is, I still think it could be made secure with a careful
>> > java.policy file (which a conscientious administrator should use
>> > anyway). David, do you think the Scala interpreter is impossible to
>> > secure or just not worth the effort? Also, what difference would it
>> > make to use Rhino, but not Scala in terms of a secure interpreter? The
>> > Scala interpreter implementation does use a new classloader and even
>> > allows you to override it and implement your own one. Try e.g. "import
>> > org.apache.esme.model.Message" or "import net.liftweb.util.Box".
>> >
>> > If the primary concern is trust in a federation, we could make it so a
>> > server is not allowed to participate in a federation if the Scala
>> > interpreter action is enabled.
>> >
>> > Cheers,
>> > Vassil
>> >
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
Re: Scala interpreter action
Posted by David Pollak <fe...@gmail.com>.
On Mon, Jul 6, 2009 at 1:43 AM, Richard Hirsch <hi...@gmail.com>wrote:
> Should I deploy with this functionality active or not?
I wouldn't. It's kinda like taping a "Hack Me" sticker onto the site. :-)
>
>
> I just did a stax deplyoment with the
> actions.scala_interpreter.enable=false
>
> D.
>
> On Mon, Jul 6, 2009 at 10:24 AM, Vassil Dichev<vd...@apache.org> wrote:
> >> Should we remove it completely from the source or should we just
> >> deactivate it by default?
> >>
> >> I agree that I wouldn't activate it in a producticve setting but it
> >> might be useful while developing.
> >
> > Granted, this might not be the best way to monitor/debug ESME (e.g. if
> > memory is so tight the JVM won't be able to create a new interpreter
> > instance or send a new message). When I implemented the feature I was
> > actually thinking of Dick's request for making it easier for ESME
> > newcomers to learn Scala. I've also spent some time thinking about
> > using ESME in a university and this feature makes a lot of sense in a
> > classroom.
> >
> > My point is, I still think it could be made secure with a careful
> > java.policy file (which a conscientious administrator should use
> > anyway). David, do you think the Scala interpreter is impossible to
> > secure or just not worth the effort? Also, what difference would it
> > make to use Rhino, but not Scala in terms of a secure interpreter? The
> > Scala interpreter implementation does use a new classloader and even
> > allows you to override it and implement your own one. Try e.g. "import
> > org.apache.esme.model.Message" or "import net.liftweb.util.Box".
> >
> > If the primary concern is trust in a federation, we could make it so a
> > server is not allowed to participate in a federation if the Scala
> > interpreter action is enabled.
> >
> > Cheers,
> > Vassil
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
Re: Scala interpreter action
Posted by Richard Hirsch <hi...@gmail.com>.
Should I deploy with this functionality active or not?
I just did a stax deplyoment with the actions.scala_interpreter.enable=false
D.
On Mon, Jul 6, 2009 at 10:24 AM, Vassil Dichev<vd...@apache.org> wrote:
>> Should we remove it completely from the source or should we just
>> deactivate it by default?
>>
>> I agree that I wouldn't activate it in a producticve setting but it
>> might be useful while developing.
>
> Granted, this might not be the best way to monitor/debug ESME (e.g. if
> memory is so tight the JVM won't be able to create a new interpreter
> instance or send a new message). When I implemented the feature I was
> actually thinking of Dick's request for making it easier for ESME
> newcomers to learn Scala. I've also spent some time thinking about
> using ESME in a university and this feature makes a lot of sense in a
> classroom.
>
> My point is, I still think it could be made secure with a careful
> java.policy file (which a conscientious administrator should use
> anyway). David, do you think the Scala interpreter is impossible to
> secure or just not worth the effort? Also, what difference would it
> make to use Rhino, but not Scala in terms of a secure interpreter? The
> Scala interpreter implementation does use a new classloader and even
> allows you to override it and implement your own one. Try e.g. "import
> org.apache.esme.model.Message" or "import net.liftweb.util.Box".
>
> If the primary concern is trust in a federation, we could make it so a
> server is not allowed to participate in a federation if the Scala
> interpreter action is enabled.
>
> Cheers,
> Vassil
>
Re: Scala interpreter action
Posted by Vassil Dichev <vd...@apache.org>.
> Upon more reflection, I think any form of code that can read/write files on
> the local filesystem and/or open TCP connections to localhost or anywhere
> else presents a danger. Think about how long it took to secure
> browser-based Java implementations. I just see a high resource consumption
> cycle of finding hole/fixing hole... all for a feature that's not part of
> the main purpose of the project.
>
> The above comments apply to Scala as well as JavaScript via Rhino... I just
> don't think it can be done securely.
>
> With that being said, what I propose is keeping the code in, having it
> disabled by default, making sure there's a huge warning associated with the
> option that it gives users a lot of power on the machine and it should only
> be enabled if you're running behind a firewall and with only known and
> trusted users. Finally, when I get the federation stuff in, I'll disable
> federation with any instance that has this feature turned on. That'll calm
> my concerns about network attacks.
You have a point. I always insisted that this feature should be off by
default and assumed it's worse than it actually is. Still, I managed
to execute a DB query through lift in the embedded Derby DB. I know
it's possible to secure the database if you use a separate process,
and you restrict the access to the property file containing the
credentials and... eventually it's better to restrict this whole class
of vulnerabilities rather than rely on admins to be able to plug every
little one of those holes.
> PS -- I really do like this feature in the abstract. I think it's cool.
> It's the former CTO of a security company part of me that rears its ugly
> head when I see stuff that allows for semi-controlled code to be executed
> from unknown parties.
All right, given the example with Rhino I was just wondering whether
there was something I was not doing right or it's just the nature of
the problem.
A similar but safer way for monitoring would be to have a set of
commands for querying different types of stats, all parsed through a
statically checked parser combinator.
Vassil
Re: Scala interpreter action
Posted by David Pollak <fe...@gmail.com>.
On Mon, Jul 6, 2009 at 1:24 AM, Vassil Dichev <vd...@apache.org> wrote:
> > Should we remove it completely from the source or should we just
> > deactivate it by default?
> >
> > I agree that I wouldn't activate it in a producticve setting but it
> > might be useful while developing.
>
> Granted, this might not be the best way to monitor/debug ESME (e.g. if
> memory is so tight the JVM won't be able to create a new interpreter
> instance or send a new message). When I implemented the feature I was
> actually thinking of Dick's request for making it easier for ESME
> newcomers to learn Scala. I've also spent some time thinking about
> using ESME in a university and this feature makes a lot of sense in a
> classroom.
>
> My point is, I still think it could be made secure with a careful
> java.policy file (which a conscientious administrator should use
> anyway). David, do you think the Scala interpreter is impossible to
> secure or just not worth the effort? Also, what difference would it
> make to use Rhino, but not Scala in terms of a secure interpreter? The
> Scala interpreter implementation does use a new classloader and even
> allows you to override it and implement your own one. Try e.g. "import
> org.apache.esme.model.Message" or "import net.liftweb.util.Box".
Upon more reflection, I think any form of code that can read/write files on
the local filesystem and/or open TCP connections to localhost or anywhere
else presents a danger. Think about how long it took to secure
browser-based Java implementations. I just see a high resource consumption
cycle of finding hole/fixing hole... all for a feature that's not part of
the main purpose of the project.
The above comments apply to Scala as well as JavaScript via Rhino... I just
don't think it can be done securely.
With that being said, what I propose is keeping the code in, having it
disabled by default, making sure there's a huge warning associated with the
option that it gives users a lot of power on the machine and it should only
be enabled if you're running behind a firewall and with only known and
trusted users. Finally, when I get the federation stuff in, I'll disable
federation with any instance that has this feature turned on. That'll calm
my concerns about network attacks.
Thanks,
David
PS -- I really do like this feature in the abstract. I think it's cool.
It's the former CTO of a security company part of me that rears its ugly
head when I see stuff that allows for semi-controlled code to be executed
from unknown parties.
>
>
> If the primary concern is trust in a federation, we could make it so a
> server is not allowed to participate in a federation if the Scala
> interpreter action is enabled.
>
> Cheers,
> Vassil
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
Re: Scala interpreter action
Posted by Vassil Dichev <vd...@apache.org>.
> Should we remove it completely from the source or should we just
> deactivate it by default?
>
> I agree that I wouldn't activate it in a producticve setting but it
> might be useful while developing.
Granted, this might not be the best way to monitor/debug ESME (e.g. if
memory is so tight the JVM won't be able to create a new interpreter
instance or send a new message). When I implemented the feature I was
actually thinking of Dick's request for making it easier for ESME
newcomers to learn Scala. I've also spent some time thinking about
using ESME in a university and this feature makes a lot of sense in a
classroom.
My point is, I still think it could be made secure with a careful
java.policy file (which a conscientious administrator should use
anyway). David, do you think the Scala interpreter is impossible to
secure or just not worth the effort? Also, what difference would it
make to use Rhino, but not Scala in terms of a secure interpreter? The
Scala interpreter implementation does use a new classloader and even
allows you to override it and implement your own one. Try e.g. "import
org.apache.esme.model.Message" or "import net.liftweb.util.Box".
If the primary concern is trust in a federation, we could make it so a
server is not allowed to participate in a federation if the Scala
interpreter action is enabled.
Cheers,
Vassil
Re: Scala interpreter action
Posted by Richard Hirsch <hi...@gmail.com>.
Should we remove it completely from the source or should we just
deactivate it by default?
I agree that I wouldn't activate it in a producticve setting but it
might be useful while developing.
D.
On Sun, Jul 5, 2009 at 10:06 PM, David
Pollak<fe...@gmail.com> wrote:
> Folks,
>
> While this feature is interesting, I have to ask that we remove it.
>
> It's a security hole. It's problematic in that it makes the messages sent
> to any server with the feature enabled insecure. Once we get federation (I
> know, I know I keep promising and not delivering federation), then we're
> going to have to care more about trusting servers in the given federation.
> Allowing one of those servers to be compromised by simply having this
> feature turned on, then it makes the federation one of suspicion.
>
> Or, put another way, Outlook allowed for arbitrary execution of VB code in
> payloads which led to 10 years of virus/worm fighting. Now, I know this
> feature is not arbitrary code execution of message payloads, there will be
> someone creates a script that has a code injection vulnerability in it.
>
> So, while this feature feels kind good, I'd much rather see the feature done
> as execution of JavaScript code via Rhino in a high security sandbox (which
> is possible with Rhino.)
>
> Thanks,
>
> David
>
> On Sun, Jul 5, 2009 at 5:45 AM, Vassil Dichev <vd...@apache.org> wrote:
>
>> Hello everyone,
>>
>> There is now an action which interprets the text of a message as Scala
>> code and returns back the result. Here's how it works and some things
>> you can do with it.
>>
>> First of all, you need to enable this feature. You will be able to
>> create "scala" actions even if it's disabled, but they won't do
>> anything. To turn it on, use this setting in e.g. default.props (the
>> only one you can rely on in a ):
>>
>> actions.scala_interpreter.enable=true
>>
>> *Note*: It's sensible to have this feature off by default, as you will
>> gain full control of the JVM in the classloader context of the
>> application. Unless there are security manager restrictions, you might
>> be able to execute OS code, shut down the JVM, modify the database,
>> inspect live objects and possibly change them, etc. This could be both
>> a threat and an advantage.
>>
>> Now it's time to set up our embedded scala interpreter:
>> 1. Create a pool, let's call it e.g. "scalapool"
>> 2. Create an action, which has a filter for the newly created pool. In
>> our example, the filter is "pool:scalapool". The action itself is just
>> "scala". In theory, you could use any filter, but the special symbols
>> necessary for hashtags and users interfere with Scala code. Besides,
>> except for a pool, you don't have much control what gets in your
>> timeline, and I doubt that any unintended message there is valid Scala
>> code.
>> 3. Send some Scala code to scalapool.
>>
>> Let's see what we can do with Scala in ESME:
>>
>>
>> * Calculator
>>
>> Try these:
>>
>> - arithmetic calculations:
>> 3 + 3
>>
>> - string operations:
>> "olleH" reverse
>>
>> -operate on lists, e.g. sum numbers:
>> List(1,2,3,4,5).foldLeft(0)(_+_)
>>
>> As we can see, the result is displayed in a new message, which is a
>> reply to the current one, and is in the same pool. The message source
>> is "scala".
>>
>> Printing to the console won't do what you expect (you won't see it in
>> your reply), so don't use it.
>>
>>
>> * Background execution.
>>
>> Each new message is executed in a separate interpreter. While this has
>> some disadvantages (you lose the bindings for each consecutive
>> execution), there are some advantages to this approach. For instance,
>> you could have several computations execute in parallel, and the
>> previous won't block the next one. Try these messages, one right after
>> the other:
>>
>> {Thread.sleep(10000); "later"}
>> "now"
>>
>> The first message will wait for 10 seconds and then return the string
>> "later". If during those 10 seconds you manage to enter the second
>> message "now", the result will be returned before the result of the
>> first message.
>>
>> This, of course, is an expensive way to schedule reminder messages. If
>> you want it, request a feature in Jira :)
>>
>>
>> * Monitoring
>>
>> -free memory in the JVM:
>> Runtime.getRuntime.freeMemory
>>
>> -total JVM memory:
>> Runtime.getRuntime.totalMemory
>>
>> -current date and timezone on the system:
>> new java.util.Date
>>
>> -get a JVM property, e.g. the JVM version:
>> System.getProperty("java.vm.version")
>>
>>
>> It would be very interesting how this runs in Stax. I tried to use
>> code which works in restricted environments (e.g. I read about
>> problems with classloaders in OSGi). As a whole, I think a sandboxed
>> environment like this is ideal for running ESME with the embedded
>> Scala interpreter, as it offsets the security implications somewhat.
>> As with all powerful features, I would think twice before enabling it
>> in a corporate environment where lots of important messages are
>> stored. On the other hand, I wouldn't hesitate to use it as a training
>> tool in a class where students are able to execute their Scala
>> assignments and the teacher can observe in real time how everyone is
>> doing.
>>
>> So, what do you think? Is this something you find useful? Is there
>> something I missed?
>>
>> Have fun,
>> Vassil
>>
>> P.S. This is another mail in a growing list, which will (hopefully
>> soon) find its way to the wiki documentation or on the blog.
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
Re: Scala interpreter action
Posted by Vassil Dichev <vd...@apache.org>.
> While this feature is interesting, I have to ask that we remove it.
>
> It's a security hole. It's problematic in that it makes the messages sent
> to any server with the feature enabled insecure. Once we get federation (I
> know, I know I keep promising and not delivering federation), then we're
> going to have to care more about trusting servers in the given federation.
> Allowing one of those servers to be compromised by simply having this
> feature turned on, then it makes the federation one of suspicion.
>
> Or, put another way, Outlook allowed for arbitrary execution of VB code in
> payloads which led to 10 years of virus/worm fighting. Now, I know this
> feature is not arbitrary code execution of message payloads, there will be
> someone creates a script that has a code injection vulnerability in it.
>
> So, while this feature feels kind good, I'd much rather see the feature done
> as execution of JavaScript code via Rhino in a high security sandbox (which
> is possible with Rhino.)
Actually, the Scala interpreter is already creating a classloader
sandbox in a way which is probably similar to Rhino.
I just tried to load ESME or Lift classes and I couldn't. I thought
that's detracting from ESME's functionality, but now I see it is a
security bonus. The only classes accessible are from the Scala
compiler and library jars. The reason for this is that the interpreter
is creating a separate classloader:
http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/compiler/scala/tools/nsc/Interpreter.scala#L143
This would mean that the code executed is subject to a similar lever
of isolation as e.g. different J2EE apps running side-by-side in a
secure J2EE container. It is still possible to shut down the JVM, but
not tamper with the data of ESME running in the same JVM. Shutting
down the JVM and executing OS code can (and should) be controlled by
setting up security policies.
Anyway, one cannot trust a server if you cannot trust its
administrators. Nobody could stop a malicious administrator from
compiling a modified version of ESME, which would be compromised even
without the Scala embedded interpreter.
I do think the feature should be inspected by a security professional;
we have 2 choices here: remove it and wait for the expert to say yes,
or keep it and wait for an expert to say no. If David still insists
it's a vulnerability, I'll revert the commit.
Vassil
Re: Scala interpreter action
Posted by David Pollak <fe...@gmail.com>.
Folks,
While this feature is interesting, I have to ask that we remove it.
It's a security hole. It's problematic in that it makes the messages sent
to any server with the feature enabled insecure. Once we get federation (I
know, I know I keep promising and not delivering federation), then we're
going to have to care more about trusting servers in the given federation.
Allowing one of those servers to be compromised by simply having this
feature turned on, then it makes the federation one of suspicion.
Or, put another way, Outlook allowed for arbitrary execution of VB code in
payloads which led to 10 years of virus/worm fighting. Now, I know this
feature is not arbitrary code execution of message payloads, there will be
someone creates a script that has a code injection vulnerability in it.
So, while this feature feels kind good, I'd much rather see the feature done
as execution of JavaScript code via Rhino in a high security sandbox (which
is possible with Rhino.)
Thanks,
David
On Sun, Jul 5, 2009 at 5:45 AM, Vassil Dichev <vd...@apache.org> wrote:
> Hello everyone,
>
> There is now an action which interprets the text of a message as Scala
> code and returns back the result. Here's how it works and some things
> you can do with it.
>
> First of all, you need to enable this feature. You will be able to
> create "scala" actions even if it's disabled, but they won't do
> anything. To turn it on, use this setting in e.g. default.props (the
> only one you can rely on in a ):
>
> actions.scala_interpreter.enable=true
>
> *Note*: It's sensible to have this feature off by default, as you will
> gain full control of the JVM in the classloader context of the
> application. Unless there are security manager restrictions, you might
> be able to execute OS code, shut down the JVM, modify the database,
> inspect live objects and possibly change them, etc. This could be both
> a threat and an advantage.
>
> Now it's time to set up our embedded scala interpreter:
> 1. Create a pool, let's call it e.g. "scalapool"
> 2. Create an action, which has a filter for the newly created pool. In
> our example, the filter is "pool:scalapool". The action itself is just
> "scala". In theory, you could use any filter, but the special symbols
> necessary for hashtags and users interfere with Scala code. Besides,
> except for a pool, you don't have much control what gets in your
> timeline, and I doubt that any unintended message there is valid Scala
> code.
> 3. Send some Scala code to scalapool.
>
> Let's see what we can do with Scala in ESME:
>
>
> * Calculator
>
> Try these:
>
> - arithmetic calculations:
> 3 + 3
>
> - string operations:
> "olleH" reverse
>
> -operate on lists, e.g. sum numbers:
> List(1,2,3,4,5).foldLeft(0)(_+_)
>
> As we can see, the result is displayed in a new message, which is a
> reply to the current one, and is in the same pool. The message source
> is "scala".
>
> Printing to the console won't do what you expect (you won't see it in
> your reply), so don't use it.
>
>
> * Background execution.
>
> Each new message is executed in a separate interpreter. While this has
> some disadvantages (you lose the bindings for each consecutive
> execution), there are some advantages to this approach. For instance,
> you could have several computations execute in parallel, and the
> previous won't block the next one. Try these messages, one right after
> the other:
>
> {Thread.sleep(10000); "later"}
> "now"
>
> The first message will wait for 10 seconds and then return the string
> "later". If during those 10 seconds you manage to enter the second
> message "now", the result will be returned before the result of the
> first message.
>
> This, of course, is an expensive way to schedule reminder messages. If
> you want it, request a feature in Jira :)
>
>
> * Monitoring
>
> -free memory in the JVM:
> Runtime.getRuntime.freeMemory
>
> -total JVM memory:
> Runtime.getRuntime.totalMemory
>
> -current date and timezone on the system:
> new java.util.Date
>
> -get a JVM property, e.g. the JVM version:
> System.getProperty("java.vm.version")
>
>
> It would be very interesting how this runs in Stax. I tried to use
> code which works in restricted environments (e.g. I read about
> problems with classloaders in OSGi). As a whole, I think a sandboxed
> environment like this is ideal for running ESME with the embedded
> Scala interpreter, as it offsets the security implications somewhat.
> As with all powerful features, I would think twice before enabling it
> in a corporate environment where lots of important messages are
> stored. On the other hand, I wouldn't hesitate to use it as a training
> tool in a class where students are able to execute their Scala
> assignments and the teacher can observe in real time how everyone is
> doing.
>
> So, what do you think? Is this something you find useful? Is there
> something I missed?
>
> Have fun,
> Vassil
>
> P.S. This is another mail in a growing list, which will (hopefully
> soon) find its way to the wiki documentation or on the blog.
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
Re: Scala interpreter action
Posted by Richard Hirsch <hi...@gmail.com>.
Hi,
Looks great. I like the monitoring capabilities.
I already added it to the wiki
(http://cwiki.apache.org/confluence/display/ESME/Scala+Action) and
will turn it on tomorrow when I do the weekly Stax deplyoment.
D.
On Sun, Jul 5, 2009 at 2:45 PM, Vassil Dichev<vd...@apache.org> wrote:
> Hello everyone,
>
> There is now an action which interprets the text of a message as Scala
> code and returns back the result. Here's how it works and some things
> you can do with it.
>
> First of all, you need to enable this feature. You will be able to
> create "scala" actions even if it's disabled, but they won't do
> anything. To turn it on, use this setting in e.g. default.props (the
> only one you can rely on in a ):
>
> actions.scala_interpreter.enable=true
>
> *Note*: It's sensible to have this feature off by default, as you will
> gain full control of the JVM in the classloader context of the
> application. Unless there are security manager restrictions, you might
> be able to execute OS code, shut down the JVM, modify the database,
> inspect live objects and possibly change them, etc. This could be both
> a threat and an advantage.
>
> Now it's time to set up our embedded scala interpreter:
> 1. Create a pool, let's call it e.g. "scalapool"
> 2. Create an action, which has a filter for the newly created pool. In
> our example, the filter is "pool:scalapool". The action itself is just
> "scala". In theory, you could use any filter, but the special symbols
> necessary for hashtags and users interfere with Scala code. Besides,
> except for a pool, you don't have much control what gets in your
> timeline, and I doubt that any unintended message there is valid Scala
> code.
> 3. Send some Scala code to scalapool.
>
> Let's see what we can do with Scala in ESME:
>
>
> * Calculator
>
> Try these:
>
> - arithmetic calculations:
> 3 + 3
>
> - string operations:
> "olleH" reverse
>
> -operate on lists, e.g. sum numbers:
> List(1,2,3,4,5).foldLeft(0)(_+_)
>
> As we can see, the result is displayed in a new message, which is a
> reply to the current one, and is in the same pool. The message source
> is "scala".
>
> Printing to the console won't do what you expect (you won't see it in
> your reply), so don't use it.
>
>
> * Background execution.
>
> Each new message is executed in a separate interpreter. While this has
> some disadvantages (you lose the bindings for each consecutive
> execution), there are some advantages to this approach. For instance,
> you could have several computations execute in parallel, and the
> previous won't block the next one. Try these messages, one right after
> the other:
>
> {Thread.sleep(10000); "later"}
> "now"
>
> The first message will wait for 10 seconds and then return the string
> "later". If during those 10 seconds you manage to enter the second
> message "now", the result will be returned before the result of the
> first message.
>
> This, of course, is an expensive way to schedule reminder messages. If
> you want it, request a feature in Jira :)
>
>
> * Monitoring
>
> -free memory in the JVM:
> Runtime.getRuntime.freeMemory
>
> -total JVM memory:
> Runtime.getRuntime.totalMemory
>
> -current date and timezone on the system:
> new java.util.Date
>
> -get a JVM property, e.g. the JVM version:
> System.getProperty("java.vm.version")
>
>
> It would be very interesting how this runs in Stax. I tried to use
> code which works in restricted environments (e.g. I read about
> problems with classloaders in OSGi). As a whole, I think a sandboxed
> environment like this is ideal for running ESME with the embedded
> Scala interpreter, as it offsets the security implications somewhat.
> As with all powerful features, I would think twice before enabling it
> in a corporate environment where lots of important messages are
> stored. On the other hand, I wouldn't hesitate to use it as a training
> tool in a class where students are able to execute their Scala
> assignments and the teacher can observe in real time how everyone is
> doing.
>
> So, what do you think? Is this something you find useful? Is there
> something I missed?
>
> Have fun,
> Vassil
>
> P.S. This is another mail in a growing list, which will (hopefully
> soon) find its way to the wiki documentation or on the blog.
>