Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6705999

problem with Essbase and StarOffice while using GTK and JRE 1.6

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Cannot Reproduce
    • Icon: P2 P2
    • None
    • 6
    • client-libs
    • None
    • generic
    • generic

      Short description:
      ==================
      StarOffice and the Sun internally used Essbase Calc plugin are conflicting when both of them are using GTK UI and JRE 1.6. There is an issue with Java awt and the corresponding XError handler.

      Long description:
      ==================
      Here some more details about the issue from our development about the Essbase problem:

      Essbase plugin wants to draw its java widgets using gtk's native drawing routines
      to achieve a system like look. However since the plugin runs in a java thread when
      running inside StarOffice/OpenOffice.org, this means that two threads access gtk
      at the same time. This leads to problems in two ways, one of which is easily fixable.

      The first problem is that the underlying X11 implementation needs to be made thread
      safe by using XInitThreads. This does not happen early enough in Star/OpenOffice which
      can of course easily be remedied.

      The second problem however is less trivial. The second (java/Essbase) thread draws
      using gtk and while using X11's APIs involuntarily gets XError events delivered.
      These XErrors would normally be consumed by Star/OpenOffice's XError event handler
      and handled appropriately. Gtk however sets its own XError event handler all the
      time and of course has different assumptions about how to handle them; in our
      case it usually ends up with the default behaviour terminating the application.

      This problem cannot be fixed by Star/OpenOffice, it can also not be fixed by Essbase
      plugin. The gtk specific implementation of the java awt could set its own XError
      handler (which would be able to ignore XErrors while drawing widgets), however this
      could generate a concurrency problem (in setting the handler by SO and java) as well
      as it might not work because the very gtk methods called could reset that handler
      (as gtk has shown a tendency to do). It may turn out that the only way to fix this
      would be in gtk itself.

            art Artem Ananiev (Inactive)
            duke J. Duke
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: