You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <pa...@yahoo.com> on 2001/03/28 06:49:22 UTC

Xcommander

I guess for Peter really...

Could Xcommander be used in a similar way to Beanshell?  i.e running commands like cp, ls, mv etc
(providing an app using it could make available those commands).

Should not Xcommander move from cornerstone/demo to somewhere more significant?





=====
Regards - Paul H
====
CVS -1, Perforce +1

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/?.refer=text

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


RE: Xcommander

Posted by Paul Hammant <pa...@yahoo.com>.
> > What sort of refactoring required.
> 
> I looked at the code again, and refactoring is probably the
> wrong word. It currently doesn't support all primitive types
> correctly, nor does it support RMI-style commands (I want it
> to be able to support remote objects directly). Secondly,
> it provides no security management.

RMI Commands a different command listener I'd say.

Security?  Avalon/Phoenix already provides a TLS wrapper mechanism for socket listeners right?
That would tackle privacy.  For Authernication we need a user subsystem.  James has one, FtpServer
has one.  Time for a central reference interface?  Implementations for a "Avalon", Windows,
Solaris, Linux via JNI?
 
> > What I am looking for
> > =====================
> > 
> > Inside Jesktop I have a 98% full functioned beanshell working.  
> > It sould be nice to use it to fire
> > commands at server components in the same VM (or an alternative VM)
> 
> You'd still have to write the tool to parse the commands
> to java code. And when you've done that, you might want to
> leave the xml out of the picture and just execute the
> supplied commands directly...
> XML is tremendously useful as an inter-application communication
> tool, and also as a storage mechanism. The inner-app uses are
> much more limited...

Well, Although it's one VM for Jesktop, it's definately inter-application.

> To me, it sounds like you're looking for a tool that converts
> strings in the form of 'new James.AddUserCmd("Fred")' to actual
> java. 

No I have that already - Beanshell. It's a very cool comand line tool that having had syntax
parser generated by JavaCC, can takre string args and automatically turn them into Java objects. 
Each Beanshell command is a bsh file.  Here is the one for "cd". It's executed like so
cd("C:\winning-lottery-numbers");

  bsh.help.cd = "usage: cd( path )";
  /*
	Additions by Kevin Raulerson, 
        http://www.spin.com.mx/~kevinr/
  */
  cd( String pathname ) {
      file = pathToFile( pathname );
	  if ( file.exists() && file.isDirectory() )
	 	super.bsh.cwd = file.getCanonicalPath();
  	  else
          print( "No such directory: "+pathname);
  }

All the commands/classes to execute must be in the VM/classloader at time of execution.  Why I'm
interested is that I will reflection style be able to fire commands to Avalon blocks that are not
inside the sights of my current classloader.  I.e. they are a) in the same VM, but a different
classloader (Avalon separates blocks right?) or b) a differnt machine or VM.

E.g. I could create a bsh _script_ for the aforementioned James function (long suffering in terms
of an example on my behalf) : 

  addJamesUser( String domain, String userName ) {
    xcommandSender = this.interpreter.get("xcommand-sender");
    xcommandSender.sendCommand(domain, 
      xcommandSender.makeXMLCommand("new-user",userName));
  }

> The most simple solution would be jPython or RMI.

JPython - to add to my list of things to look at.

RMI? Not sure it's relevant to my needs.

> Of course, I'd still like to see XCommander in widespread use,
> so don't let me stop you =)

:-))

I am reluctant to fork code though. I'd rather see the jakarta hosted Xcommander evolve.

> 
> > Incidentally: I'd reckon a toXML() would be better than 
> > toString() on the commands.
> 
> me too. This needs fixing...go ahead ;)

Consider it done.  I'll begin a checkout on latest versions of Avalon/Ph/C'stone.  When it's
finished in an hour I'll make the change and book it back.

Leo, could I invite you to take a look at Jesktop?  If you could download it, build it,
hot-install Beanshell, run it, then type one of the commands on
http://www.jesktop.org/portedapps.html (Beanshell), you might see what I am driving at.

-PH

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/?.refer=text

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


RE: Xcommander

Posted by Leo Simons <ma...@leosimons.com>.
> I think Ant is too tied to the *real* command line for my 
> purposes. I like the ideas behind
> Xcommander.

=)

> > XCommander was not designed for complex commands. It is easy
> > to add in those capabilities, but doing so _right_ would
> > require significant refactoring. If someone does that, then
> > I'm +1. -1 until then.
> 
> What sort of refactoring required.

I looked at the code again, and refactoring is probably the
wrong word. It currently doesn't support all primitive types
correctly, nor does it support RMI-style commands (I want it
to be able to support remote objects directly). Secondly,
it provides no security management.

> What I am looking for
> =====================
> 
> Inside Jesktop I have a 98% full functioned beanshell working.  
> It sould be nice to use it to fire
> commands at server components in the same VM (or an alternative VM)

You'd still have to write the tool to parse the commands
to java code. And when you've done that, you might want to
leave the xml out of the picture and just execute the
supplied commands directly...
XML is tremendously useful as an inter-application communication
tool, and also as a storage mechanism. The inner-app uses are
much more limited...
To me, it sounds like you're looking for a tool that converts
strings in the form of 'new James.AddUserCmd("Fred")' to actual
java. The most simple solution would be jPython or RMI.
Of course, I'd still like to see XCommander in widespread use,
so don't let me stop you =)

> Incidentally: I'd reckon a toXML() would be better than 
> toString() on the commands.

me too. This needs fixing...go ahead ;)

cheers,

LSD

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


RE: Xcommander

Posted by Paul Hammant <pa...@yahoo.com>.
Leo,
 
> > Could Xcommander be used in a similar way to Beanshell?  i.e 
> > running commands like cp, ls, mv etc
> > (providing an app using it could make available those commands).
> 
> definately. I'm making mods on it (very much alpha) which
> will separate 'the engine' from the 'demo'. This should allow
> it to do about anything java can do.

:-))
 
> I'm not sure if it is smart though to take this too far -
> the Ant engine is more powerful and more stable for jobs
> like this.

I think Ant is too tied to the *real* command line for my purposes. I like the ideas behind
Xcommander.
 
> Here's the alternative: hook ant2 up to a socket using Avalon's
> wrapper model, add authentication support and a wealth of
> XCommands, and you've got java-based xml-aware remote control
> of a machine.

Way beyond my abilities :-(
 
> > Should not Xcommander move from cornerstone/demo to somewhere 
> > more significant?
> 
> XCommander was not designed for complex commands. It is easy
> to add in those capabilities, but doing so _right_ would
> require significant refactoring. If someone does that, then
> I'm +1. -1 until then.

What sort of refactoring required.

What I am looking for
=====================

Inside Jesktop I have a 98% full functioned beanshell working.  It sould be nice to use it to fire
commands at server components in the same VM (or an alternative VM)

Sort of syntax I am looking for ->

bsh> xcmd("localhost","james","<adduser user=\"fred\"/>");

or 

bsh> xcmd("localhost","james",new James.AddUserCmd("Fred"));

Note : james is only an example.  

Incidentally: I'd reckon a toXML() would be better than toString() on the commands.  I argue this
the whole time (but never get anywhere) as the only way for debugging purposes you can see
instance numbers is to *not* override toString().  This is useful if you doubt whether you have
one or two instances of apparently the same thing.

Note2 : Beanshell changed license (at 1.1 alpha 5) to dual LGPL/SPL.  This is allows it to be used
in netbeans apparently.  Good for the community of course.



=====
Regards - Paul H
====
CVS -1, Perforce +1

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/?.refer=text

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


RE: Xcommander

Posted by Leo Simons <ma...@leosimons.com>.
> I guess for Peter really...

I'll have a go at it anyway =)

> Could Xcommander be used in a similar way to Beanshell?  i.e 
> running commands like cp, ls, mv etc
> (providing an app using it could make available those commands).

definately. I'm making mods on it (very much alpha) which
will separate 'the engine' from the 'demo'. This should allow
it to do about anything java can do.

I'm not sure if it is smart though to take this too far -
the Ant engine is more powerful and more stable for jobs
like this.

Here's the alternative: hook ant2 up to a socket using Avalon's
wrapper model, add authentication support and a wealth of
XCommands, and you've got java-based xml-aware remote control
of a machine.

> Should not Xcommander move from cornerstone/demo to somewhere 
> more significant?

XCommander was not designed for complex commands. It is easy
to add in those capabilities, but doing so _right_ would
require significant refactoring. If someone does that, then
I'm +1. -1 until then.

cheers!

LSD

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


Re: Xcommander

Posted by Peter Donald <do...@apache.org>.
At 08:49  27/3/01 -0800, Paul Hammant wrote:
>I guess for Peter really...
>
>Could Xcommander be used in a similar way to Beanshell?  i.e running
commands like cp, ls, mv etc
>(providing an app using it could make available those commands).
>
>Should not Xcommander move from cornerstone/demo to somewhere more
significant?

I would like to wait and see how commons turns out first. (Just in case you
are not aware commons is another project at Jakarta aimed at providing
reusable server components). Currently it could not sit directly under
commons due to their charter. However there is an insider involved trying
to make them see sense ;)

If commons turns out to be a no-go for whatever reason - I was going to try
to collaborate with a few others to setup a jakarta-avalon-agora or
something similar. This would basically be like commons except more
distributed control and much more freedom etc. In this place I would like
to see anyone be able to work on a product (say Xcommander) without being
bound to my foul coding conventions and more free to implement what you
want etc.


Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


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