Hi Elliot, Depending on the amount of coupling between the bundles and your main application that you like, I think there are basically two options:
1) Push: Expose windows etc. through some service your framework places in the registry, so bundles can add elements to it 2) Pull: Have your bundle expose elements they want to add to the GUI through some service they publish and let the application actually add them to the GUI Push is more straightforward to implement I think. You would have your main application publish a service with methods like: Window getMainWindow(); Window getSearchDialog(); Etc. The bundles would request this service, call the methods to get to the windows and then add their GUI elements to it. This implies a high(er) coupling between your application and the bundles though, because the bundles would have to be aware of the layout of the GUI, which windows are available etc. Then there is pull. Your bundles would publish a service with methods like: Panel getMainPanel(); Panel[] getPopupPanels(); Etc. In this variation the coupling between the main application and the bundles is lower. The bundles don't really 'know' what the main application's GUI looks like, they just inform the application of the GUI elements they provide and leave it up to the app itself to decide where these elements should go. In both variations you can either directly expose Swing / AWT etc classes, or you can make a more abstract API that hides such implementation details, for example using methods like: List<Action> getActions() Where Action is some class you define. Then the application would decide whether to translate these actions to items in the main menu, items in a context menu, push buttons or whatever. If you need maximum flexibility and don't mind high coupling, Push is probably most straightforward to implement and has the advantage that bundles can do unforeseen things. If you need access to Swing / AWT etc in your bundles, you should Instruct Felix to expose these classes to your bundles by placing Their package names in a list passed to Felix using Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA Good luck! -Stijn -----Original Message----- From: Elliot Huntington [mailto:elliot.hunting...@gmail.com] Sent: donderdag 22 april 2010 17:41 To: users@felix.apache.org Subject: OSGi newbie looking for pointers Hi: I just started researching OSGi this past week so I'm very new to it and have never developed an application using it. But I am very interested in learning this technology. In my research I've learned that the different bundles can communicate with each other by publishing/consuming services to/from the service registry. I am confused though how this process works. For example I want to create a bare bones OSGi GUI application. I want this application to only manage the lifecycle of the gui (open the main frame and handle the shutdown/closing of the program). Then, I would like to create other projects (bundles) that provide all the features for this application via plugins. I'm thinking that the best way to do this would be to create the main GUI application with an instance of embedded Felix. Given this scenario, how would the different pluggins/bundles know how to modify the main GUI and add functionality to it? Does the GUI itself need to provide hooks into it and if so how does it do that? If any of you have any example code or tutorials you could point me to I would appreciate it. Thanks, Elliot --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
