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 <[EMAIL PROTECTED]> 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
