You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Donald Woods <dw...@apache.org> on 2007/04/18 22:36:35 UTC
Why are we including native code in Geornimo (aka. JLine)
Is this not a disaster waiting to happen? 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. "
-Donald
-------- Original Message --------
Subject: Re: Running multiple instances of geronimo
Date: Mon, 9 Apr 2007 15:43:27 -0700
From: Jason Dillon <ja...@planet57.com>
Reply-To: dev@geronimo.apache.org
To: dev@geronimo.apache.org
References: <12...@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 <ja...@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/
Re: Why are we including native code in Geornimo (aka. JLine)
Posted by Guillaume Nodet <gn...@gmail.com>.
The only license which is important is the one which is used for the current
software you use. A relicense can not effect previously released software.
So I don't think there is any issue there.
Projects sometimes relicense their software under a more friendly
license (from a AL perspective) so that more projects can use it.
On 4/19/07, Donald Woods <dw...@apache.org> wrote:
>
> What is the ASF stance on including code that was previously licensed as
> GPL?
>
> From the Change Log section on their website http://jline.sourceforge.net/
>
> 0.9.0 2005-01-23
> - Changed license from GPL to BSD.
>
>
> -Donald
>
> Kevan Miller wrote:
> >
> > On Apr 19, 2007, at 9:35 AM, Aaron Mulder wrote:
> >
> >> On 4/19/07, Ted Kirby <ted.kirby@gmail.com
> >> <ma...@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.
> >>
> >
> > Agreed. IIRC, we had a similar discussion when JLine was first
> > introduced into Geronimo. I'm comfortable with JLine. If there are
> > explicit issues, which we aren't recognizing, please let us know...
> >
> > --kevan
>
>
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
Re: Why are we including native code in Geornimo (aka. JLine)
Posted by Donald Woods <dw...@apache.org>.
What is the ASF stance on including code that was previously licensed as
GPL?
From the Change Log section on their website http://jline.sourceforge.net/
0.9.0 2005-01-23
- Changed license from GPL to BSD.
-Donald
Kevan Miller wrote:
>
> On Apr 19, 2007, at 9:35 AM, Aaron Mulder wrote:
>
>> On 4/19/07, Ted Kirby <ted.kirby@gmail.com
>> <ma...@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.
>>
>
> Agreed. IIRC, we had a similar discussion when JLine was first
> introduced into Geronimo. I'm comfortable with JLine. If there are
> explicit issues, which we aren't recognizing, please let us know...
>
> --kevan
Re: Why are we including native code in Geornimo (aka. JLine)
Posted by Kevan Miller <ke...@gmail.com>.
On Apr 19, 2007, at 9:35 AM, Aaron Mulder wrote:
> On 4/19/07, Ted Kirby <te...@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.
Agreed. IIRC, we had a similar discussion when JLine was first
introduced into Geronimo. I'm comfortable with JLine. If there are
explicit issues, which we aren't recognizing, please let us know...
--kevan
Re: Why are we including native code in Geornimo (aka. JLine)
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 4/19/07, Ted Kirby <te...@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 <ja...@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 <ja...@planet57.com>
> > > Reply-To: dev@geronimo.apache.org
> > > To: dev@geronimo.apache.org
> > > References: <12...@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 <ja...@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/
> > >
> > >
> > >
> >
> >
>
>
Re: Why are we including native code in Geornimo (aka. JLine)
Posted by Ted Kirby <te...@gmail.com>.
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 <ja...@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
>
>
>
Re: Why are we including native code in Geornimo (aka. JLine)
Posted by Jason Dillon <ja...@planet57.com>.
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
Re: Why are we including native code in Geornimo (aka. JLine)
Posted by Ted Kirby <te...@gmail.com>.
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?
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 <ja...@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 <ja...@planet57.com>
> > Reply-To: dev@geronimo.apache.org
> > To: dev@geronimo.apache.org
> > References: <12...@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 <ja...@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/
> >
> >
> >
>
>
Re: Why are we including native code in Geornimo (aka. JLine)
Posted by Jason Dillon <ja...@planet57.com>.
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 <ja...@planet57.com>
> Reply-To: dev@geronimo.apache.org
> To: dev@geronimo.apache.org
> References: <12...@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 <ja...@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/
>
>
>
Re: Why are we including native code in Geornimo (aka. JLine)
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Some good points. See inline
On Apr 18, 2007, at 4:36 PM, Donald Woods wrote:
> Is this not a disaster waiting to happen?
Isn't everything we do a disaster waiting to happen :)
> 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. "
>
>
This was discussed previously and based on the usage it seemed like a
reasonable approach. If someone has an all Java alternative that
would be excellent. Rather than speculate on where things might fail
I'd rather since it hasn't broken anything (yet) I think it would be
better to focus on the specific areas where it is broken. To date
I'm unaware of any.
> -Donald