OSGi Best and Worst Practices
Download as PPT, PDF5 likes2,403 views
The document discusses best practices and controversies for using OSGi frameworks. It recommends not programming against the OSGi framework directly, managing dependencies carefully, using services appropriately, testing code thoroughly, and considering debates around Require-Bundle versus Import-Package and when to use services versus extensions. The document also provides a resource for additional questions.
OSGi Best and Worst Practices
- 1. OSGi Best and Worst Practices Chris Aniszczyk — Red Hat Jeff McAffer — EclipseSource Martin Lippert — it-agile Paul VanderLei — Band XI
- 4. Sometimes it better not to know Ignorance is bliss
- 5. It's bad mojo to pollute the POJO
- 6. Your code sucks. Versioning can help.
- 7. Good fences make good neighbors
- 10. Use services
- 13. Not everything should be a service
- 14. ...and OSGi made all the apps dynamic
- 15. The Easter Bunny is dead
- 17. If you don't test it, it doesn't work!
- 18. OSGi is not a religion
- 20. Lets look at some controversy Now some controversy
Editor's Notes
- #3: Jeff
- #4: Jeff Don’t be too surprised OSGi is rather elegant It is minimalist and unpresumptious This is awesome as it keeps system size down But it is a system's level programming model. - APIs are low level - Dynamics are hard, cause, well, dynamic stuff is hard and there is not a lot of help Fundamentally, OSGi is an implementation detail, an enabling element. For most people is it something to be hidden from view
- #5: Sometimes its better not to know whats around you Programming POJOs help isolate you from the OSGi gorp Really we are talking about dependency injection and a style of coding. - Encourages reuse - eases testing - Clarifies design and dependencies This is a pervasive theme throughout this talk In short: Its bad mojo to pollute the POJO
- #7: Chris
- #8: chris
- #9: Martin
- #10: Jeff Imagine this Hello <cable co> my TV is not working string another line Keep doing that until the price of copper skyrockets and someone steals the pole Know the bundle food chain Minimizing your dependencies improves reuse Improves freedom of action
- #11: Paul Using services as the unit of reuse is preferred over just sharing packages: -lifecycle management -pluggability DS is better than Service Tracker: -for a bundle needing two services..... -100 lines of code vs 8 lines of XML -error-prone -required hours of effort from experts DS: -encourages good componentizaiton -allows lazy classloading -nice tooling ServiceTracker: -too easily ties your code to OSGi -makes testing and reuse more difficult -pollutes the POJO (bad mojo)
- #12: this is for a bundle requiring two services
- #14: Paul just because something in your application needs to be registered, it does not mean that you should make that thing a service and use the service registry -whiteboard pattern can easily fall into this trap -example: student registers for a course. student is NOT a service -core & other utility classes -HashMapFactoryService counter-example
- #15: Jeff OSGi is a bit of a fairy tale story. The small but secretly powerful modularity system That runs around brings dynamism to everyone Yeah, well, sorry, but fairy tales are just that, fairy tales. <any kids in the room?>
- #16: Oh, and BTW, …
- #17: Dynamics are not free Real work is needed Analogous to running multi-threaded – you have to code for it. not for everyone Relate to Eclipse adoption
- #18: Paul
- #19: Paul OSGi is not omnipresent -If you’re spending all your time writing OSGi-related code, you’re doing it wrong! OSGi is not infallible -Plenty of crap in the OSGi holy scriptures: Wire Admin, Event Admin… -OSGi is not omnipotent Not everything OSGi provides is ideal for your application ConfigAdmin
- #21: Martin
- #22: Martin
- #23: Martin
- #24: shameless plug