BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage OSGi Content on InfoQ

  • Modular Java: Declarative Modularity

    The fourth of the Modular Java series covers declarative modularity. It describes how components can be declaratively defined and wired together, without having a code dependency on OSGi APIs. Declarative services will be used to write POJOs together dynamically, such that code no longer needs to explicitly register or consume OSGi services, and without any start ordering dependencies.

  • Classloader Acrobatics: Code Generation with OSGi

    Porting great infrastructure to OSGi often means solving complex classloading problems. This article is dedicated to the frameworks that face the hardest issues in this area: those that do dynamic code generation. Incidentally these are also the coolest frameworks: AOP wrappers, ORM mappers, and service proxy generators are just a few examples.

  • Modular Java: Dynamic Modularity

    Modularity is an important aspect of large Java systems. Build scripts and projects are often split up into modules in order to improve the build, but this is rarely taken into account at runtime. This third part of the Modular Java series discusses dynamic modularity, how a bundle's classes are resolved, how they can come and go, and how they can communicate with each other.

  • Modular Java: Static Modularity

    Modularity is an important aspect of large Java systems. Build scripts and projects are often split up into modules in order to improve the build, but this is rarely taken into account at runtime. This second part of the Modular Java series discusses static modularity, the creation of bundles, how to install them into an OSGi engine and how to set up (versioned) dependencies between bundles.

  • Modular Java: What Is It?

    Over the last few years, modularity for Java has been an active discussion topic. From the (now defunct) JSR 277 to the recognition of JSR 291 and the ongoing JSR 294, modularity is seen as a necessary step in Java's evolution. Even future JVM-based languages like Scala are considering modularity. So, what does modularity mean, and why should you care?

  • Service Dynamics: the lazy man's way

    This article describes "the hardest topic in OSGi, how to deal with service dynamics," based on personal experience. Two factors, concurrency and direct service references, make the problem "fiendishly hard." An import and an export policy should form a comprehensive doctrine for dealing with service dynamics and the article explores two export policies with their corresponding doctrines.

  • Why Do We Need Distributed OSGi?

    Recently, an early release draft of a Distributed OSGi requirements and design document has been published, long with a reference implementation as part of Apache CXF. In a new article, Eric Newcomer writes about the current status of distributed OSGi and explains the reasons for standardizing it in the first place, and its significance to the OSGi specification and community.

  • Java 7 Module System Concerns

    Java module systems has received a lot of attention lately. One reason for that was the controversy regarding JSR-277 which partially duplicated OSGi. Another was the plans for Java 7. In this article Lukas Krecan gives us a round-up of the current solutions and presents his concern on upcoming solutions like project Project Jigsaw and JSR-294.

  • Domain Driven Design and Development In Practice

    In this article, Srini Penchikala discusses Domain Driven Design and Development from a practical stand-point. The article looks at architectural and design guidelines and best practices that can be used in a DDD project. It also talks about the impact of various design concerns like Persistence, Caching, Transaction Management, Security, Code Generation etc in domain model implementation effort.

  • Eric Newcomer on the future of OSGi

    Eric Newcomer, co-chair of the OSGi Enterprise work group, talks about the evolution of OSGi and it's relationship to SOA and ESB. He discusses how he thinks OSGi will evolve over the coming years and whether or not it makes sense for Sun to adopt OSGi as the container model of choice."

  • An Update on Spring 2.0 Final

    Spring 2.0 was initially supposed to come out in June/July, why the delay? InfoQ interviewed the Spring team - based on massive community feedback, the team has chosen to delay the launch to Sept 26th in order work on asynchronous JMS capabilities, JPA, the new JSP form tag library, OSGi integration, documentation, and backwards compatibility.

BT