geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Kirby" <ted.ki...@gmail.com>
Subject Re: Why are we including native code in Geornimo (aka. JLine)
Date Thu, 19 Apr 2007 22:00:59 GMT
Thanks for all the replies and info, especially details from Jason!

I apologize for not doing my full homework. I missed the community
discussion of using JLine in my search:
http://issues.apache.org/jira/browse/GERONIMO-2216.  Given that things
work if JLine is not fully supported on a platform as Jason describes,
and of course given that the community has already discussed and
accepted JLine, I withdraw my concerns.

Thanks,
Ted Kirby

On 4/19/07, Jason Dillon <jason@planet57.com> wrote:
> 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.

Good!  Wouldn't want any "back doors" for hackers to potentially
exploit in the server! :)

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