OSGi Best and Worst Practices
âąAls PPT, PDF herunterladenâą
5 gefĂ€llt mirâą2,397 views
A presentation I gave with Jeff McAffer, Paul Vanderlei and Martin Lippert at EclipseCon 2010.
Empfohlen
Empfohlen
Weitere Àhnliche Inhalte
Mehr von Chris Aniszczyk
Mehr von Chris Aniszczyk (20)
KĂŒrzlich hochgeladen
KĂŒrzlich hochgeladen (20)
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
- 3. Â
- 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
- 11. Â
- 12. Â
- 13. Not everything should be a service
- 14. ...and OSGi made all the apps dynamic
- 15. The Easter Bunny is dead
- 16. Â
- 17. If you don't test it, it doesn't work!
- 18. OSGi is not a religion
- 19. Â
- 20. Lets look at some controversy Now some controversy
Hinweis der Redaktion
- Jeff
- 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
- 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
- Chris
- chris
- Martin
- 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
- 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)
- this is for a bundle requiring two services
- 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
- 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?>
- Oh, and BTW, âŠ
- 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
- Paul
- 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
- Martin
- Martin
- Martin
- shameless plug