• Like
  • Save
Tales from the OSGi trenches
Upcoming SlideShare
Loading in...5
×
 

Tales from the OSGi trenches

on

  • 9,429 views

Slides of my "Tales from the OSGi trenches" presentation at ApacheCon Europe 2009

Slides of my "Tales from the OSGi trenches" presentation at ApacheCon Europe 2009

Statistics

Views

Total Views
9,429
Views on SlideShare
8,890
Embed Views
539

Actions

Likes
13
Downloads
288
Comments
2

8 Embeds 539

http://grep.codeconsult.ch 371
http://dev.day.com 104
http://www.slideshare.net 24
http://osgilook.com 21
http://osgilook.wordpress.com 16
http://translate.googleusercontent.com 1
http://www.linkedin.com 1
http://www.slideee.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

12 of 2

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Tales from the OSGi trenches Tales from the OSGi trenches Presentation Transcript

    • OSGi Tales from the Trenches Bertrand Delacretaz Senior R&D Developer, Day Software, www.day.com Apache Software Foundation Member and Director bdelacretaz@apache.org blog: http://grep.codeconsult.ch twitter: @bdelacretaz Special thanks to: ApacheCon Europe 2009, Amsterdam Filippo Diotalevi (osgilook.com) slides revision: 2009-03-25 and The Day R&D team for additional input! OSGi tales from the trenches
    • What? Share our experience using Apache Felix at Day, for a major rewrite of our content management products. More than two years working with OSGi, very high impact on developers, customers, service people, mostly in a positive way. OSGi is no silver bullet either. silve r OSGi tales from the trenches
    • Ok but what? the GOOD the BAD the UGLY and the FUTURE symbols by ppdigital , o0o0xmods0o0oon and clarita, on morguefile.com OSGi tales from the trenches
    • Introduction OSGi tales from the trenches
    • First a warning is not an OSGi guru! I’m just a poor lonesome user... OSGi tales from the trenches
    • OSGi ? OSGi™ The Dynamic Module System for Java™ http://www.osgi.org (see also Wikipedia) Consortium founded 1999, 100 companies. Initially meant for mobile devices. Now moving to server-side, fast. Eclipse, LinkedIn, GlassFish, WSO2, WebSphere and many others. @apache: Felix, ServiceMix, Sling, CXF, Tuscany and more, growing. OSGi tales from the trenches
    • Trenches? family of content management products, R&D team of about 30 built on Apache Sling, http://www.day.com/cq5 http://jackrabbit.apache.org uses Apache Felix and http://felix.apache.org Jackrabbit http://incubator.apache.org/sling OSGi tales from the trenches
    • What we use from OSGi Bundles (using Maven plugins) Lifecycle, Service Tracker Configurations and Felix Web Console Declarative Services (using Maven plugins) Sling’s jcrinstall module (bundles and configs loaded from the JCR repository) Log, HTTP, Event services presented by Carsten at 10:30 OSGi tales from the trenches
    • Famous quotes OSGi tales from the trenches
    • Famous Quotes, #1 “Effectively, OSGi brings many of the desirable aims of SOA into the JVM.quot;” Paul Fremantle http://pzf.fremantle.org/2009/02/wso2-carbon- part-1.html OSGi tales from the trenches
    • Famous Quotes, #2 “Each (OSGi) bundle can serve as a micro application, having it's own lifecycle, having it's own citizens and each bundle can carefully decide which objects to expose to the outside world” Peter Rietzler http://peterrietzler.blogspot.com/2008/12/is-osgi-going- to-become-next-ejb-bubble.html OSGi tales from the trenches
    • Famous Quotes, #3 “OSGi is great, but the tooling is not quite there yet. Not every library is a bundle and many JARs don’t have OSGi manifests” Matt Raible in http://blog.linkedin.com/2008/06/23/osgi-at-linkedin- integrating-spring-dm-part-1/ OSGi tales from the trenches
    • Famous Quotes, #4 “The lifecycle model of OSGi makes life complicated. Actually, tracking services and managing all the aspects of what to do when services come and go is nasty” Peter Rietzler http://peterrietzler.blogspot.com/2008/12/is-osgi-going- to-become-next-ejb-bubble.html OSGi tales from the trenches
    • Famous Quotes, #5 “The challenge for the coming year is to make OSGi more in line with the expectations of the average J2EE programmer because we see that need” Peter Kriens in a comment at http://peterrietzler.blogspot.com/2008/12/is-osgi-going- to-become-next-ejb-bubble.html OSGi tales from the trenches
    • Famous Quotes, #6 “OSGi makes quot;impossiblequot; things easy: hot deploy/upgrade, service discovery, ... and trivial things hard: hibernate, tag libraries, even deploying a simple war!” But, for the first time in my career, I see software reusability that works: service reusability. Filippo Diotalevi OSGi tales from the trenches
    • Our opinion OSGi tales from the trenches
    • The Good OSGi tales from the trenches
    • Modularity OSGi bundle Classloading distinct from Public packages class visibility. Metadata Bundles as Private packages reusable components. At last! Matchless picture: Alvimann on morguefile.com OSGi tales from the trenches
    • Declarative Services /** * Excerpts from a Sling Servlet, processes *.query.json requests * Uses Felix’s maven-scr-plugin annotations * @scr.component immediate=quot;truequot; * @scr.service interface=quot;javax.servlet.Servletquot; * @scr.property name=quot;sling.servlet.resourceTypesquot; value=quot;sling/servlet/defaultquot; * @scr.property name=quot;sling.servlet.extensionsquot; value=quot;jsonquot; * @scr.property name=quot;sling.servlet.selectorsquot; value=quot;queryquot; */ public class JsonQueryServlet extends SlingSafeMethodsServlet { /** @scr.reference (injected by framework) */ private SlingRepository repo; // activate(ComponentContext) and deactivate(ComponentContext) // methods are called by framework if present Annotated Java class + ... } Maven plugins == OSGi service OSGi tales from the trenches
    • Clean API Just a few basic examples... OSGi tales from the trenches
    • Dynamic loading / unloading Just copy bundle jar to Sling’s JCR repository (WebDAV) Bundle activated and started. (using Sling’s jcrinstall module) OSGi tales from the trenches
    • Plugins for everything Content editors based on Servlets JCR node properties Mime-type based handlers Debugging/monitoring tools Content renderers and decorators Legacy integration gateways Mail and messaging services etc, etc... OSGi tales from the trenches
    • Plugins: ServiceTracker // Enumerate currently available AuthenticationHandler // services, and select the one to use ServiceTracker st = new ServiceTracker( bundleContext, AuthenticationHandler.class.getName()); ServiceReference[] sr = st.getServiceReferences(); for (int i = 0; i < sr.length; i++) { AuthenticationHandler h = (AuthenticationHandler) authHandlerTracker.getService(services[i]); // ... OSGi tales from the trenches
    • Legacy/customer code OSGi bundle Ugly or incompatible Public packages code Metadata segregated via private packages Private packages OSGi tales from the trenches
    • Private / public packages maven-bundle-plugin instructions: <Export-Package> sling.jcr.jackrabbit.server.security </Export-Package> <Private-Package> sling.jcr.jackrabbit.server.impl.* </Private-Package> OSGi tales from the trenches
    • The Bad OSGi tales from the trenches
    • Granularity is a hard problem How many bundles? > 100 currently in cq5 How to handle “implementation details” libraries. Extra bundles or private packages? Strict version management required. Are we there yet? OSGi tales from the trenches
    • Clean up those packages! OSGi bundle Clean separation of Public packages interface and Metadata implementation packages required Private packages but when done! OSGi tales from the trenches
    • Integration testing required V4.22 V4.5 V7.4 V1.03 V3.21 V3.22 V4.2 V5.11 V5.3 V2.13 V6.54 V1.05 In-system V1.11 V6.4 V1.03 testing? V3.4 V6.4 V3.2 V5.43 V3.2 V2.4 but when done! V5.6 OSGi tales from the trenches
    • Is OSGi scary? “OSGi is difficult to sell - it is adopted in some really visible products,like websphere, glassfish, eclipse, but people don't know that.” (Filippo Diotalevi) Why so many bundles? Where’s my J2EE? Is the book ready? Whaddyamean “provisioning”? OSGi tales from the trenches
    • Is it too early? me: Starting two years later might have helped avoid initial pains and incomplete implementations. Felix Meschberger: If we would have done that, we would be nowhere near where we are now! Server-side OSGi is still fairly new... OSGi tales from the trenches
    • The Ugly OSGi tales from the trenches
    • Asynchronous startup 7 14 11 17 V4.22 V4.5 V7.4 15 1 V1.03 V3.21 V3.22 11 3 V4.2 2 10 V5.11 V5.3 V2.13 19 V6.54 16 V1.05 Threading 5 6 “unpredictable” V1.11 18 V6.4 issues? V1.03 13 startup order 8 V3.4 V6.4 12 4 V3.2 9 V5.43 19 V3.2 V2.4 Is the system ready now? 20 V5.6 Caused by Declarative Services, not by OSGi itself. OSGi tales from the trenches
    • Unpredictable assemblies V4.22 V4.5 V7.4 V1.03 V3.21 V3.22 V4.2 V5.11 V5.3 V2.13 V6.54 V1.05 V1.11 V6.4 V1.03 V3.4 V6.4 V3.2 V5.43 V3.2 V2.4 Spot the monsters! Security and lots of discipline would help V5.6 OSGi tales from the trenches
    • Testing OSGi tales from the trenches
    • Testing? Integration JUnit JUnit testing, and mocks, with OSGI OSGi, HTTP no OSGi Test the code Test bundles Test assemblies Required. in realistic in realistic Sufficient? conditions conditions Many examples in Sling We don’t use this at this time. Sling launchpad and jcrinstall OSGi tales from the trenches
    • JUnit testing w/mocks JUnit Example, using jmock.org: and mocks, JsonReaderTest in Sling’s contentloader module. no OSGi @org.junit.Test public void testEmptyObject() No OSGi needed, throws Exception { fast! this.mockery.checking(new Expectations() {{ But what am I allowing(creator).createNode(null, null, null); testing exactly? inSequence(mySequence); Sometimes hard to allowing(creator).finishNode(); follow or modify. inSequence(mySequence); }}); this.parse(quot;quot;); } https://svn.eu.apache.org/repos/asf/incubator/sling/trunk/bundles/jcr/contentloader/src/test/java/org/apache/sling/jcr/contentloader/internal/JsonReaderTest.java OSGi tales from the trenches
    • Integration tests, OSGi + HTTP Bundles under test cargo-maven2 plugin starts webapp surefire-plugin runs tests HTTP HTTP Felix OSGi console Felix OSGi framework Sling app (cargo-maven2 plugin) JUnit tests Maven Examples in Sling’s launchpad/testing and jcrinstall modules. OSGi tales from the trenches
    • Integration test: JsonRenderingTest public void testRecursiveInfinity() throws IOException { final Map<String, String> props = new HashMap<String, String>(); props.put(quot;textquot;, testText); props.put(quot;a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/yquot;, quot;yesquot;); final String url = testClient.createNode(postUrl, props); final String json = getContent(url + quot;.infinity.jsonquot;, Simulate actual CONTENT_TYPE_JSON); usage! assertJavascript(testText, json, quot;out.print(data.text)quot;); assertJavascript(quot;yesquot;, json, quot;out.print(data.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y)quot;); } OSGi tales from the trenches
    • Unpredictable assemblies V4.22 V4.5 V7.4 V1.03 V3.21 V3.22 V4.2 V5.11 V5.3 V2.13 V6.54 V1.05 V1.11 V6.4 V1.03 V3.4 V6.4 V3.2 V5.43 V3.2 V2.4 Integration testing helps! V5.6 OSGi tales from the trenches
    • The Future OSGi tales from the trenches
    • OSGi @day, 2 years from now Developers got used to it (and read the book). Frameworks and tools improved. Distributed OSGi? Maybe. Customers understand OSGi and like it.. Apache Sling paved the way. OSGi tales from the trenches
    • Do we need more features? Today we use: Bundles (using Maven plugins) Lifecycle, Service Tracker Configurations and Felix Web Console Declarative Services (using Maven plugins) Sling’s jcrinstall module Log, HTTP, Event services Later: Deployment packages. Security maybe. More? Not really - tame what we use! OSGi tales from the trenches
    • Conclusions Good? Bad? Ugly? OSGi tales from the trenches
    • Conclusions OSGi is great for modularity OSGi fosters better structured code Dynamic services and plugins Tooling needs to improve, but usable OSGi skills need to improve! Asynchronous startup can be problematic if using declarative services OSGi tales from the trenches