geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: Why are we including native code in Geornimo (aka. JLine)
Date Thu, 19 Apr 2007 19:39:38 GMT
On Apr 19, 2007, at 6:02 AM, Ted Kirby wrote:
> It would seem that an AG goal is portability to many platforms.  This
> seems implicit with java, and certainly depends on java being
> supported on many platforms.
>
> By using JLine, we are letting that package determine on which
> platforms AG will run.

Um, no not at all.  Any platform that Java 1.5 runs on G can  
technically run on, and *most* of them are windows or posix systems  
and will have a improved CLI interface ala JLine, and any others  
which are not supported (which I dont' know of any right now) will  
have an slightly degraded CLI interface.  And everything should work  
exactly the same.


> I would feel more comfortable with this
> decision if JLine were an Apache project.

How does that make any difference at all?


> Going forward with JLine
> raises the barrier of entry for a platform to support Geronimo: it
> must insure that JLine runs on it, with possible native code required.
> Is this something we really want to do?

This is simply not the case.  Did you read how JLine works at all?   
I've explained it already a few times on this list in the past.

In short, there is no need to do any platform verification.  If JLine  
fails to load, then no harm is done, only the CLI interface degrades  
slightly.

There is only native JNI code on Windows, which is uber tiny to set a  
stream into unbuffered mode ( http://jline.cvs.sourceforge.net/jline/ 
jline/src/main/native/ ) , and on posix stty is executed to achieve  
the same goal w/o needing any JNI muck.


> Is JLine loading thread-safe?

AFAIK yes.


> As we consider AG scaling with multiple
> repositories and server instances
> (http://cwiki.apache.org/GMOxDOC20/multiple-repositories-and-server- 
> instances.html),
> as well as keeping as much of AG in read-only file systems as
> possible, will JLine continue to work?  Will it become a systems
> administration headache?  How much of one, and is this what we want?

Yes, it will continue to work, though there could a wrinkle here and  
there which I can not predict.  Right now I don't anticipate anything  
major.


> Are there alternatives to JLine?

Sure, there is Java-Readline ( http://java- 
readline.sourceforge.net/ ), which is LGPL and uses Readline which is  
GPL, and is completely JNI based.  Java-Readline can also use the  
more license friendly Editoline or Geline libraries, though is still  
painfully native.

JLine is the only available library right now that provides Readline- 
like features to Java w/minimal (very, very, very) minimal native  
muck (tiny DLL on windows and exec of stty for all others) and which  
is BSD licensed.

In Java 6 there is a System.console() which provides about 1/10th the  
features of JLine, but could potentially be used on Java 6 platforms  
inside of JLine to extend the range of portability.  But I'm not sure  
how well this will work, since JLine can be used with regular  
streams, which I am doing with GShell's telnet server right now.   
Seems like System.console() is yet another feature that someone at  
Sun hacked in without thinking about the bigger picture.  I almost  
wish that Sun would just use JLine in their VM, but leave it to them  
to bastardize it (like they did with logging).


> Jline seems to be used by GShell.  Will GShell go into AG 2.0?

That remains to be seen, I've had no time to work on GShell as I've  
been entirely too busy supporting build and TCK process muck.

I think, probably not on the initial drop.  Maybe on a revision, or  
as a plugin.


> Will it have adequate security so that users may prevent hackers from
> logging into their server's GShell?

The first release will probably not have any security, as right now  
its just a note on my list of things TODO.  GShell asis is more like  
a tech preview, and is missing some key features.  It certainly won't  
be enabled by default... especially since right now only the telnet  
server is working, I've yet to finish the ssh impl.


> Currently, JLine seems to be used only by geronimo-deploy-tools
> InputPrompt class.  This seems a small usage with a high architectural
> and portability cost.  If GShell won't make 20, might it be possible
> to remove JLine from 20, and bring it back with GShell post 20?

There is no reason to drop JLine.  Its a tiny awesome library, which  
has not caused anyone any problems that I know of to date.  It is  
completely harmless.  If you don't believe me then go experiment for  
yourself, its really easy to test/validate.  See http:// 
jline.sourceforge.net/ and play with:

     java -cp jline-demo.jar jline.example.PasswordReader "*"

and/or force it to fallback mode:

     java -cp jline-demo.jar - 
Djline.terminal=jline.UnsupportedTerminal  
jline.example.PasswordReader "*"


--jason



Mime
View raw message