Swing & OSGi - Devoxx 09

  • 4,752 views
Uploaded on

At Devoxx 09, Xander Tamminga and I told the tale of the perils in using Swing in an OSGi-based application. The details can be found at http://lsd.luminis.nl/swing-and-osgi .

At Devoxx 09, Xander Tamminga and I told the tale of the perils in using Swing in an OSGi-based application. The details can be found at http://lsd.luminis.nl/swing-and-osgi .

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,752
On Slideshare
0
From Embeds
0
Number of Embeds
5

Actions

Shares
Downloads
36
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • You have a window with a table in it. The table is created before the window sets its look and feel; you need to restart the table-providing bundle before the table’s look and feel is correct.
  • Even worse: two menu’s with different look and feel’s in a single window.
  • A table gets put into a scrollpane _before_ this scrollpane is part of the AWT hierarchy; hence, a NPE.
    (The ColumnHeader only gets created when the scrollpane receives a ‘notify’ from the window)
  • A table gets put into a scrollpane _before_ this scrollpane is part of the AWT hierarchy; hence, a NPE.
    (The ColumnHeader only gets created when the scrollpane receives a ‘notify’ from the window)
  • How do we create an OSGi-aware Swing application anyway?
  • - Startlevels are about all bundles; besides, the NPE before cannot be solved by this.
  • We start out with an application with consisting of a host and nested children.
  • We use OSGi to resolve our services.
  • Host -> Childeren -> and their Childeren

    finally, all components can initialize themselves.
  • Since every component now uses the same service interface, we add some service properties to keep them separate; we could also use subclasses of ComponentProvider
  • The ComponentProvider is a very simple interfaces, which separates these three steps.
  • - Some dependency management mechanism makes this easier, since we rely on service resolution (the Apache Felix Dependency Manager has been used successfully in the past)
    - Application composition is determined at application start.
    - So, don’t create your components on a framework thread

Transcript

  • 1. Swing and OSGi - please play nice by Angelo van der Sijpt / Xander Tamminga
  • 2. Has this ever happened to you? www.devoxx.com
  • 3. Has this ever happened to you? www.devoxx.com
  • 4. Has this ever happened to you? www.devoxx.com
  • 5. Has this ever happened to you? www.devoxx.com
  • 6. Has this ever happened to you? www.devoxx.com
  • 7. Has this ever happened to you? www.devoxx.com
  • 8. www.devoxx.com Swing & OSGi
  • 9. Why’s that? Different design philosophies & assumptions OSGi is dynamic by definition Swing is built to be static www.devoxx.com
  • 10. How to fix that? Startlevels Which may have more impact than desired May not even solve the problem All UI in a single bundle But we don’t want that! www.devoxx.com
  • 11. How to really fix that? www.devoxx.com
  • 12. How to really fix that? www.devoxx.com
  • 13. How to really fix that? www.devoxx.com
  • 14. How to really fix that? www.devoxx.com
  • 15. The ComponentProvider www.devoxx.com
  • 16. The ComponentProvider www.devoxx.com
  • 17. Notes The problem gets worse with complexity Dependency management helps You give up flexibility at runtime Remember to use the EDT correctly www.devoxx.com
  • 18. That’s it! See the Luminis LSD blog for details and code http://lsd.luminis.nl/swing-and-osgi www.devoxx.com