geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: Why are we including native code in Geornimo (aka. JLine)
Date Thu, 19 Apr 2007 13:35:29 GMT
On 4/19/07, Ted Kirby <ted.kirby@gmail.com> wrote:
> I am uncomfortable with what feels to me like an architectural deviation.
>
> 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.  I would feel more comfortable with this
> decision if JLine were an Apache project.  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?

I'm not following your logic.  According to the documentation, on
platforms where JLine does not have a native library, it uses
essentially the same code we used to use.  So it doesn't seem to me
that there really are any portability limitations.  It may "work
better" on certain platforms (that is, no possibility of password
characters appearing on the command line), but on all other platforms,
the behavior is no worse than before (that is, we try hard to wipe out
password characters, but the occasional one shows up briefly).

Still, back to the original issue, if there is some problem with where
we set the tempdir for various configurations (and therefore how JLine
deals with the native libraries), we should fix that.

Thanks,
       Aaron

> Is JLine loading thread-safe?  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?
>
> Are there alternatives to JLine?
>
> Jline seems to be used by GShell.  Will GShell go into AG 2.0?  Will
> it have adequate security so that users may prevent hackers from
> logging into their server's GShell?
>
> 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?
>
> Ted Kirby
>
> On 4/18/07, Jason Dillon <jason@planet57.com> wrote:
> > On Apr 18, 2007, at 1:36 PM, Donald Woods wrote:
> > > Is this not a disaster waiting to happen?
> >
> > Windows is a disaster waiting to happen... oh wait its happened already.
> >
> >
> > > Do we really need to include this package just for usage by the
> > > following?
> > > modules\geronimo-deploy-tool\src\main\java\org\apache\geronimo
> > > \deployment\cli\InputPrompt.java
> > >
> > > From their website -
> > > " JLine is not 100% pure Java. On Windows, it relies on a .dll file
> > > to initialize the terminal to be able to accept unbuffered input.
> > > However, no installation is necessary for this: when initialized,
> > > JLine will dynamically extract the DLL to a temporary directory and
> > > load it. For more details, see the documentation for the
> > > jline.WindowsTerminal class.
> > >
> > > On UNIX systems (including Macintosh OS X), JLine will execute the
> > > stty command to initialize the terminal to allow unbuffered input.
> > > For more details, see the documentation for the jline.UnixTerminal
> > > class.
> > >
> > > For both Windows and UNIX systems, JLine will fail to initialize if
> > > it is run inside a strict security manager that does not allow the
> > > loading of libraries, writing to the file system, or executing
> > > external programs. However, for most console applications, this is
> > > usually not the case. "
> >
> > If for some crazy reason the terminal detection fails, then it goes
> > back into fallback mode, so the worst thing that could happen is the
> > old method of getting passwords by erase line/rewrite line will be
> > used.  What we used to have in Geronimo to support that is now part
> > of JLine itself.
> >
> > I don't see any reason to yank out JLine... unless you can
> > demonstrate a specific environment where this use blows up
> > completely... and really in that case I'd rather just get JLine fixed
> > to not blow up.  But I have yet to find that environment where it
> > explodes on impact.  We have been using this for a while now and so
> > far no one has noticed any problems, or at least no one reported any
> > problems.
> >
> > By the way when I finally get done with this build crapo and get back
> > to GShell, then it makes heavy use of the completion and history
> > features of JLine, which makes for a really nice interface when you
> > telnet/ssh into the server to run commands or execute admin scripts.
> >
> > --jason
> >
> >
> > >
> > > -Donald
> > >
> > > -------- Original Message --------
> > > Subject: Re: Running multiple instances of geronimo
> > > Date: Mon, 9 Apr 2007 15:43:27 -0700
> > > From: Jason Dillon <jason@planet57.com>
> > > Reply-To: dev@geronimo.apache.org
> > > To: dev@geronimo.apache.org
> > > References: <122165.18246.qm@web31712.mail.mud.yahoo.com>
> > >
> > > The extraction is handled automatically by the JLine library at
> > > runtime and will extract to wherever java.io.tmpdir is set to for the
> > > invoking JVM.
> > >
> > > What is the issue?  I don't understand what the problem is you are
> > > trying to solve related to the jline.dll.  You should not have to do
> > > anything at all related to this file.
> > >
> > > --jason
> > >
> > >
> > > On Apr 9, 2007, at 3:34 PM, Anita Kulshreshtha wrote:
> > >
> > >>   Thanks Jason! The jline.dll was extracted to i1/var/temp and
> > >> i2/var/temp for instances named i1 and i2. But the shutdown config
> > >> expects it in var/temp. If the default server, i.e. the one using
> > >> 'var'
> > >> is not started, the jline.dll is not extracted to var/temp. Could we
> > >> extract it to var/temp even without starting the default server? When
> > >> is the extraction done?
> > >>
> > >> Thanks
> > >> Anita
> > >>
> > >> --- Jason Dillon <jason@planet57.com> wrote:
> > >>
> > >>> On Apr 9, 2007, at 2:49 PM, Anita Kulshreshtha wrote:
> > >>>> 3. The shutdown config is using var/temp/jline.dll. We should be
> > >>> able
> > >>>> to use a single copy of jline.dll. Where should jline.dll be put?
> > >>>
> > >>> jline.dll is dynamically extracted from the jline-*.jar and it will
> > >>> put it into whatever is used for java.io.tmpdir for the executing
> > >>> JVM.
> > >>>
> > >>> So you shouldn't need to worry about where its put.
> > >>>
> > >>> --jason
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >>
> > >> _____________________________________________________________________
> > >> _ ______________
> > >> TV dinner still cooling?
> > >> Check out "Tonight's Picks" on Yahoo! TV.
> > >> http://tv.yahoo.com/
> > >
> > >
> > >
> >
> >
>
>

Mime
View raw message