swingx
  1. swingx
  2. SWINGX-1501

SwingX QuickStart Demo fails on OS X

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 1.6.4
    • Fix Version/s: 1.6.5
    • Component/s: None
    • Labels:
      None
    • Environment:

      OS X Lion

      Description

      Turning on the console shows this is the reason...

      Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError
      at java.lang.Class.forName0(Native Method)
      at java.lang.Class.forName(Class.java:169)
      at org.jdesktop.application.utils.OSXAdapter.setHandler(OSXAdapter.java:138)
      at org.jdesktop.application.utils.OSXAdapter.setQuitHandler(OSXAdapter.java:74)
      at org.jdesktop.application.Application.create(Application.java:257)
      at org.jdesktop.application.Application$1.run(Application.java:185)
      at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
      at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:682)
      at java.awt.EventQueue.access$000(EventQueue.java:85)
      at java.awt.EventQueue$1.run(EventQueue.java:643)
      at java.awt.EventQueue$1.run(EventQueue.java:641)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
      at java.awt.EventQueue.dispatchEvent(EventQueue.java:652)
      at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
      at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
      at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
      at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
      at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
      at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
      Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission canProcessApplicationEvents)
      at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
      at java.security.AccessController.checkPermission(AccessController.java:546)
      at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
      at com.apple.eawt.Application.checkSecurity(Application.java:54)
      at com.apple.eawt.Application.<clinit>(Application.java:43)
      ... 20 more

        Activity

        Hide
        Karl Schaefer added a comment -

        First, I don't think this is a bug, well other than sloppy coding by calling Exception.printStackTrace(). Second, this is also not in our code, but in the Better Swing Application Framework code.

        You should file a bug there. I think the best they can do is mute the exception logging because we are running without permissions we cannot hook into the application handler code to plug into the native Mac menu bar.

        Karl

        Show
        Karl Schaefer added a comment - First, I don't think this is a bug, well other than sloppy coding by calling Exception.printStackTrace(). Second, this is also not in our code, but in the Better Swing Application Framework code. You should file a bug there. I think the best they can do is mute the exception logging because we are running without permissions we cannot hook into the application handler code to plug into the native Mac menu bar. Karl
        Hide
        fommil added a comment -

        If this is an upstream bug, I think you should report it - I don't know any details about how you internally use their framework and when I have done this sort of "upstream by proxy" reporting it has never worked well.

        I'll give you an example: a few years ago I found a big security hole in NetBeans and reported it. They said "not our problem, report it with Glassfish". Glassfish turned round and said "not our problem, report it with NetBeans". A few months ago, both parties finally admitted that they were both doing things badly and were incredibly embarrassed about how major the security hole was. It took me to write an exploit to get them to both pay attention. The exploit gave user-level access to any computer running NetBeans to any user on the network (or the internet if it was a direct connection) if the developer was creating J2EE apps.

        So, long story short, I don't agree with bug reporting by proxy. I think you should report the bug as I do when users submit bug reports to me which end up being upstream.

        Show
        fommil added a comment - If this is an upstream bug, I think you should report it - I don't know any details about how you internally use their framework and when I have done this sort of "upstream by proxy" reporting it has never worked well. I'll give you an example: a few years ago I found a big security hole in NetBeans and reported it. They said "not our problem, report it with Glassfish". Glassfish turned round and said "not our problem, report it with NetBeans". A few months ago, both parties finally admitted that they were both doing things badly and were incredibly embarrassed about how major the security hole was. It took me to write an exploit to get them to both pay attention. The exploit gave user-level access to any computer running NetBeans to any user on the network (or the internet if it was a direct connection) if the developer was creating J2EE apps. So, long story short, I don't agree with bug reporting by proxy. I think you should report the bug as I do when users submit bug reports to me which end up being upstream.
        Hide
        kleopatra added a comment -

        My two-and-a-half cents:

        assuming you mean the webstartable demo on the SwingX project home: that's an application build with SwingX and other frameworks, not part of the SwingX framework. As unfortunate and embarassing a not-functioning show-case might be, SwingX doesn't guarantee that application as a whole but only the SwingX parts of it. In other words: by-proxy or not, it's not upstream of SwingLabs-demos, but not of SwingX. This issue might be better placed in the swinglabs-demo project: there I would suggest to keep it open until somebody - preferably a mac user like yourself - has incentive enough to dig into it.

        That said: will try to nudge someone from the bsaf team into having a look, at best it might be already fixed in the upcoming release.

        Show
        kleopatra added a comment - My two-and-a-half cents: assuming you mean the webstartable demo on the SwingX project home: that's an application build with SwingX and other frameworks, not part of the SwingX framework. As unfortunate and embarassing a not-functioning show-case might be, SwingX doesn't guarantee that application as a whole but only the SwingX parts of it. In other words: by-proxy or not, it's not upstream of SwingLabs-demos, but not of SwingX. This issue might be better placed in the swinglabs-demo project: there I would suggest to keep it open until somebody - preferably a mac user like yourself - has incentive enough to dig into it. That said: will try to nudge someone from the bsaf team into having a look, at best it might be already fixed in the upcoming release.
        Hide
        fommil added a comment -

        Thanks. Then it's a bug with "www" which needs to be referred upstream :-P

        Show
        fommil added a comment - Thanks. Then it's a bug with "www" which needs to be referred upstream :-P
        Hide
        kleopatra added a comment - - edited

        darn, one not too many:

        it's not upstream of SwingLabs-demos, but not of SwingX

        should be:
        it's upstream of SwingLabs-demos, but not of SwingX

        So yeah, it should be on www, but the swinglabs-www:

        http://java.net/jira/browse/SWINGLABS_DEMOS/component/14544

        and yeah, there I would keep it open: might get fixed or not, by us or by others .. no need for strong opinions

        For, let's keep it here as-is, just for reference

        Show
        kleopatra added a comment - - edited darn, one not too many: it's not upstream of SwingLabs-demos, but not of SwingX should be: it's upstream of SwingLabs-demos, but not of SwingX So yeah, it should be on www, but the swinglabs-www: http://java.net/jira/browse/SWINGLABS_DEMOS/component/14544 and yeah, there I would keep it open: might get fixed or not, by us or by others .. no need for strong opinions For, let's keep it here as-is, just for reference
        Hide
        kleopatra added a comment -

        fyi: the bug report over at bsaf is http://kenai.com/jira/browse/BSAF-122

        Show
        kleopatra added a comment - fyi: the bug report over at bsaf is http://kenai.com/jira/browse/BSAF-122
        Hide
        kleopatra added a comment -
        Show
        kleopatra added a comment - related issue in demos http://java.net/jira/browse/SWINGLABS_DEMOS-2
        Hide
        kleopatra added a comment -

        @Karl,

        not entirely sure if it's only a sloppy stacktrace printing: the recently updated report (also discussed in the forum) over in the demos states that it actually doesn't start.

        Don't know when/where exactly a WhateverException triggers the ExceptionInInitializerError: all catching (and the printing as well) is done on Exception, so if every possible Exception (code looks as if it were doing it) is caught it shouldn't.

        Show
        kleopatra added a comment - @Karl, not entirely sure if it's only a sloppy stacktrace printing: the recently updated report (also discussed in the forum) over in the demos states that it actually doesn't start. Don't know when/where exactly a WhateverException triggers the ExceptionInInitializerError: all catching (and the printing as well) is done on Exception, so if every possible Exception (code looks as if it were doing it) is caught it shouldn't.

          People

          • Assignee:
            Unassigned
            Reporter:
            fommil
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: