Discussions

News: Best Practices for OSGi Development and Integration

Bookmark and Share Get thread feed

  1. Best Practices for OSGi Development and Integration (5 messages)

    OSGi has been under development for a long time. In recent years it has gained some traction as an Eclipse standard. It provides a modular underpinning for Java component deployment, thus placing it at the center of modern application integration undertakings.

    OSGi has gained a reputation as an esoteric but robust offering, but also somewhat of a difficult technology to master. The veil may be lifting on OSGi; its use has grown to the point where a useful body of practical knowledge is beginning to emerge.

    For example, a look “under the hood” of OSGi was provided at the recent EclipseCon 2012 event in Reston, Virg., where OSGi expert Timothy Ward of Zuhlke Engineering discussed best practices for OSGi in the enterprise. Consultant Ward is an Apache Aries Project Management Committee member.

    Among a set of OSGi development tips from Ward are these: 

    1. Version Everything
    2. Seek Loose Coupling
    3. Don't do too much

    Read the rest of the advice in the full article over at our sister site SearchSOA.com

    Best practices for OSGi development in enterprise Java integration

     

     

    Reply to this

    Threaded Messages (5)

  2. amazing - osgi hasnt changed in last 5 yrs for entrpz java[ Go to top ]

    still steep learning curve, still same pain of specifying dependency in cloogy way, still cant have 2 jars of same kind in a dependency circle, still the the same pain of monitoring...

    no wonder spring guys moved to back burner after pushing hard for it.

     

    it may be good for eclipse plug-in development but not for enterprise web apps in java.

     

    Reply to this Reply to original

  3. Enterprise OSGI finally finalized[ Go to top ]

    I've been saying enterprise osgi is the future, but not the present, for years.

    After 2 frustrating years of rewriting the enterprise osgi spec it will be released with a reference implementation (Apache) in June including JPA JTA JNDI and the rest of Java EE. Importantly, they also did a lot of work on automating and generalizing dependency resolution. Peter Keirns and Neil Bartlett have demoed a Java editor that auto-configures a bundle when you add a class to your source code. There is a new Resolver Service and several new or enhanced supporting services designed for build tools. Source code and resource files and Maven repositories contain plenty of data which they are now using for auto-configuration. 

    Reply to this Reply to original

  4. SPI only[ Go to top ]

    I always thought that OSGi should have been:

    a) Been a kernel SPI

    b) Never seen in application code other than in manifests

    Any push beyond that was a mistake IMO and is probably one of the reasons OSGi has had the troubles its had.

    Reply to this Reply to original

  5. SPI only[ Go to top ]

    I always thought that OSGi should have been:

    a) Been a kernel SPI

    b) Never seen in application code other than in manifests

    Any push beyond that was a mistake IMO and is probably one of the reasons OSGi has had the troubles its had.

    Could it have been some change JVMshould have done  top class loading ? Allow develoeprs to specify which 'version' of a class to load ?

    Reply to this Reply to original

  6. Development[ Go to top ]

    In manifest first development, the META-INF/MANIFEST.MF file is treated as a source artefact that the developer must manually edit (though editing is usually done with assistance from GUI panels rather than with a plain text editor- Madison Pharmacy Associates

    Reply to this Reply to original