BeanShell in Phoenix [ was JCrontab 1.0RC ]

[Paul Hammant <Pa...@yahoo.com>]

Jason ,

Peter & others will wade in with some quality opinion, but I seldomn let 
that stop me from contributing mine too...

>>Personally, I have a feeling that we have to mount Beanshell into 
>>Phoenix at some point.  Either as a block, or as a value 
>>added Kernel. 
>> We could then allow telnet (or alike) into a running Phoenix 
>>machine. 
>> It is relvant to cron, because it would be a cool way to 
>>script method 
>>invocations (.bsh scripts)
>>    
>>
>Now _that_ would be a useful thing. The more I spelunked through the
>code yesterday, the more the issue seemed to be the question of how to
>administer a running server within the Phoenix design. 
>
>The idea of Beanshell being there raises a couple of questions in my
>mind though:
>
>1. I'm assuming that a client would reflect into a block directory
>interface of some sort to find and use Beanshell. Does such a thing
>exist?
>
No from block level.

We've talked about the possibility of supervisor-mode blocks in the past.

I think the better possibility would be to have a optional BeanShell 
enhanced Kernel.

>2. Likewise, Beanshell would have to find a way to do things to blocks.
>Is there a place to look up the loaded (not necessarily running)
>interfaces that takes into account all the possible Phoenix recursion
>gymnastics? 
>
Not sure.

>I'm too new to the codebase internals to know for sure. The prospect
>sure does fire the imagination though. I guess I'd better keep digging.
>
>As an aside, the reason I'm looking inside Phoenix at the moment is to
>harden it for use outside of a protected server environment. To ward off
>malicious code, I'd like it to distribute Phoenix and my app as a set of
>signed jars, and modify Phoenix to verify the jars before loading them.
>I've been using the Certificate Authority at
>http://ejbca.sourceforge.net/ to pretty good effect so far. If anyone
>has walked this road before and wants to warn me about pitfalls or point
>me at useful resources, feel free.
>  
>
V cool. Is your effort public or proprietory?

-ph


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: BeanShell in Phoenix [ was JCrontab 1.0RC ]

[Paul Hammant <Pa...@yahoo.com>]

Jason,

<snip/>

>Any input/cajoling/devil's advocacy is welcomed.
>  
>
Go for it dude.  I'm sure as you mull all the alternative, you'll tread 
a path to the-right-solution (tm).

- Paul


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: BeanShell in Phoenix [ was JCrontab 1.0RC ]

[Jason <ja...@shadowy.org>]

> We've talked about the possibility of supervisor-mode blocks 
> in the past.
> 
> I think the better possibility would be to have a optional BeanShell 
> enhanced Kernel.

<thinking out loud> 

I suppose I see the ease-of-writing benefits of thinking that way, but
I'd have thought that the kernel metaphor would point towards having a
supervisor-mode entity which Beanshell(s) could predictably use from
user-mode. As much as I like Beanshell, I don't know that there aren't
other usage scenarios that would suffer from it being anointed as the
Way To Do That. I admit that following that line of reasoning to its
logical end leads to more os-like things such as permissions and
locking, but once there's interactive access to the resources under
management, it's only a matter of time until two scripts collide. Or one
script and a block that assumes things it shouldn't. 

</thinking out loud>

Now that I've scared myself...

> >As an aside, the reason I'm looking inside Phoenix at the 
> moment is to 
> >harden it for use outside of a protected server environment. To ward 
> >off malicious code, I'd like it to distribute Phoenix and my 
> app as a 
> >set of signed jars, and modify Phoenix to verify the jars before 
> >loading them. I've been using the Certificate Authority at 
> >http://ejbca.sourceforge.net/ to pretty good effect so far. 
> If anyone 
> >has walked this road before and wants to warn me about pitfalls or 
> >point me at useful resources, feel free.
> >  
> >
> V cool. Is your effort public or proprietory?
Public, if it seems useful and practical. It has a pretty large list of
dependencies and possible setup scenarios. Perhaps worse, there are a
bunch of ways to set all the parts up and have them work but nonetheless
have effectively zero added security (or even harming it) due to things
outside the scope of the software. It seems to open up a Pandora's box
of maintaining security-related HOWTOs that I'm not sure I'm qualified
to do. 

I really want to at least return the gift to the Avalon community. If
there is a way to carve that part off, I will. Making non-verified mode
work alongside verified mode might be tricky. Making security a
parameter pretty thoroughly defeats my aims <grin>. However, obliging
all users to have a certificate verification path on startup (or even
the knowledge of what a certificate verification path _is_) seems to go
overboard the other way. 

I can say that the idea is under active consideration with a large
predisposition to return code to Avalon, and the determining factor will
almost certainly be the ability to put time into the dual-mode code
issue over and above the time required to get the base functionality
working. 

Any input/cajoling/devil's advocacy is welcomed.

Jason


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>