On 4/19/07, Ted Kirby <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> > Reply-To: dev@geronimo.apache.org
> > To: dev@geronimo.apache.org
> > References: <[EMAIL PROTECTED]>
> >
> > 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 <[EMAIL PROTECTED]> 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/
> >
> >
> >
>
>
