Sean Luke wrote:
>I find it odd that this is working: because it should not be. Here's the
>BeanShell transcript for 1.3.1:
>
>poisson[~]> java -Djava.awt.headless=true bsh.Interpreter
>BeanShell 1.3b1 - by Pat Niemeyer (email@hidden)
>bsh % Color c = new Color(5,5,5);
>kCGErrorRangeCheck : Window Server communications from outside of session
>allowed for root and console user
>only
>INIT_Processeses(), could not establish the default connection to the
>WindowServer.Abort
>
>1.4.x provides a similar error, only longer and with a stack trace.
Is that BeanShell 1.3.1 vs. 1.4.x, or Java 1.3.1 vs. 1.4.x?
If you mean Java, then the reason it fails on 1.3.1 is that headless-mode
is only present on 1.4 and higher. There is no headless capability at all
on 1.3.* or earlier, so setting the property has no effect. See the 1.4
AWT changes:
<http://java.sun.com/j2se/1.4.2/docs/guide/awt/AWTChanges.html#headless>
If you mean it fails in both versions of BeanShell, then maybe that's a
BeanShell quirk. Hard to say, with so few details.
As I understand SSH, logging into sshd gives the resulting child process a
user-ID (uid) of whoever logged in, for the typical sshd configuration.
This uid may not match the uid logged in to the main display, which will
determin who "owns" the window server's session. Or there might not be
anyone logged in to the main display (window server session) at all. Hard
to say, with so few details.
More details may help, like OS and JVM version, who's logged in to what
using which software, etc. For example, how ssh was started on Mac OS X,
whether /Applications/Utilities/X11 is running on the Mac OS X box or not,
and whether Java even knows about it if it is.
>... on OS X, Colors usually get you, headless or not, or at least that's been
>my experience. So the question is: why is it working in nc's case? It
>shouldn't be.
The original poster's stack trace makes it clear that java.awt.Toolkit's
static initializer is running, that it's loading its native library, and
that's what fails. Since a static initializer only runs when a class is
loaded, that use must be the first use of Toolkit. That happens as a
side-effect of Color's static initializer, so it's the first use of Color,
too. Read the source of Toolkit and Color for more details.
It's also noteworthy that the library-loading (or its own internal
initialization) fails, where one would expect a HeadlessException to be
thrown if there were truly a problem with headlessness. Refer to 1.4's
headless-mode docs and API annotations, especially those classes where a
HeadlessException is specifically noted as being thrown. As I read it,
Color's constructor is allowable in headless mode, but displayable
Components and some other things aren't (or may depend on Toolkit imp).
If you get a HeadlessException, that's one thing, but a failure to load a
native lib is another. So exactly what failures with Color do you see, on
which JVM versions, under what conditions?
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
