avalon-apps-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: JCrontab 1.0RC
Date Wed, 29 May 2002 10:25:47 GMT
On Sun, 26 May 2002 23:03, Jason wrote:
> > 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.

BTW there is already a telnet deamon on top of phoenix over on sourceforge ... 
telnetd was project name IIRC.

> 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?

sort of. Any Block that wishes to expose it to the JMX management subsystem 
needs to declare a "management interface" in it's BlockInfo file similar to

  <service name="com.biz.MyJMXInterface"/>

And then it is accessible via a name like


in JMX MBeanServer.

> 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 entirely. You can access some of the kernel components via their 
Management interfaces (look in the phoenix.interfaces package for services 
ending with MBean).

> 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.

Phoenix was originally designed for just that ;) I also had the requirement of 
downloading remote jars and integrating them into a running system. ie you 
download jars and add/replace services in a running kernel etc. However I was 
the only one using it and eventually it got dropped as other things took 
priority. I would definetly be interested in seeing what you come up with wrt 
to this. 

BTW probably the best place to do this would be to create a custom deployer 
that did something like

class MyDeployer extends DefaultDeployer
   protected void verify( final SarMetaData metaData,
                           final ClassLoader classLoader )
        throws VerifyException
     super.verify( metaData, classLoader );
     //do your magic here


Peter Donald

To unsubscribe, e-mail:   <mailto:avalon-apps-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-apps-dev-help@jakarta.apache.org>

View raw message