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
<management-access-point>
<service name="com.biz.MyJMXInterface"/>
</management-access-point>
And then it is accessible via a name like
application=Foo,name=myBlock,role=com.biz.MyJMXInterface
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
}
}
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
