Posts Tagged ‘OSGi’

Thomas Eichstädt-Engelen and Kai Kreuzer, both prominent figures in the open-source home automation scene, presented an engaging exploration of openHAB. Thomas, a senior consultant at innoQ with expertise in Eclipse technologies and OSGi, teamed up with Kai, a software architect at Deutsche Telekom specializing in IoT and smart homes, to demonstrate how openHAB transcends basic home control systems. Their session highlighted the project’s capabilities for geeks, running on affordable devices like the Raspberry Pi while offering advanced features such as presence simulation, sensor data visualization, and integration with calendars.

They began by challenging common perceptions of home automation, often limited to remote light switching or shutter control via smartphones. Kai and Thomas emphasized openHAB’s open-source ethos, allowing extensive customization beyond commercial offerings. The framework’s modular architecture, built on OSGi, enables easy extension to connect with diverse protocols and devices.

A live demo showcased openHAB’s runtime on embedded hardware, illustrating rule-based automation. For instance, they configured scenarios where motion sensors trigger lights or simulate occupancy during absences. Integration with Google Calendar for irrigation scheduling demonstrated practical, intelligent applications.

Thomas and Kai stressed the project’s appeal to Java and OSGi enthusiasts, featuring an Xbase-derived scripting language for defining complex logic. This allows developers to craft rules reacting to events like temperature changes or user inputs.

Core Concepts and Architecture

Kai outlined openHAB’s structure: a core runtime managing bindings to hardware protocols (e.g., Z-Wave, KNX), persistence services for data storage, and user interfaces. Bindings abstract device interactions, making the system protocol-agnostic. Persistence handles logging sensor data to databases like MySQL or InfluxDB for historical analysis.

Thomas highlighted the OSGi foundation, where bundles dynamically add functionality. This modularity supports community-contributed extensions, fostering a vibrant ecosystem.

Advanced Automation and Integration

The duo delved into rule engines, where scripts automate responses. Examples included voice commands via integrations or mobile apps notifying users of anomalies. They showcased charts displaying energy consumption or environmental metrics, aiding in optimization.

Integration with external services, like weather APIs for proactive heating adjustments, illustrated openHAB’s extensibility.

User Interfaces and Accessibility

Kai demonstrated multiple UIs: web-based dashboards, mobile apps, and even voice assistants. The sitemap concept organizes controls intuitively, while HABPanel offers customizable widgets.

Thomas addressed security, recommending VPNs for remote access and encrypted communications.

Community and Future Developments

They noted the growing community, with over 500 installations and active contributors. Future plans include simplified binding creation guides, archetypes for new developers, and enhanced UIs like MGWT.

In Q&A, they discussed hardware support and integration challenges, encouraging participation.

Thomas and Kai’s presentation positioned openHAB as a powerful, developer-friendly platform for innovative home automation, blending Java prowess with real-world utility.

Links:

• Thomas Eichstädt-Engelen on LinkedIn
• innoQ company website
• Kai Kreuzer on LinkedIn
• Deutsche Telekom company website

Kirk Knoernschild, a software developer passionate about modular systems and author of “Java Application Architecture,” explored the pervasive nature of architecture in software. Kirk, drawing from his book on OSGi patterns, challenged traditional views, arguing architecture permeates all levels—from high-level designs to code.

He invoked the “turtles all the way down” anecdote to illustrate architecture’s recursive essence: decisions at every layer impact flexibility. Kirk critiqued ivory-tower approaches, advocating collaborative, iterative practices aligning business and technology.

Paradoxically, architecture aims for change resistance yet adaptability. Temporal dimensions—decisions’ longevity—affect modularity: stable elements form foundations, volatile ones remain flexible.

Kirk linked SOA’s service granularity to modularity, noting services as deployable units fostering reuse. He emphasized patterns ensuring evolvability without rigidity.

Demystifying Architectural Paradoxes

Kirk elaborated on architecture’s dual goals: stability against volatility. He used examples where over-design stifles agility, advocating minimal upfront planning with evolutionary refinement.

Temporal hierarchies classify decisions by change frequency: strategic (years), tactical (months), operational (days). This guides layering: stable cores support variable extensions.

Granularity and Modularity Principles

Discussing granularity, Kirk warned against extremes: monolithic systems hinder reuse; overly fine-grained increase complexity. Patterns like base and dependency injection promote loose coupling.

He showcased OSGi’s runtime modularity, enforcing boundaries via exports/imports, preventing spaghetti code.

Linking Design to Temporal Decisions

Kirk connected design principles—SOLID—to temporal aspects: single responsibility minimizes change impact; open-closed enables extension without modification.

He illustrated with code: classes as small modules, packages as mid-level, OSGi bundles as deployable.

SOA and Modular Synergies

In SOA, services mirror modules: autonomous, composable. Kirk advocated aligning service boundaries with business domains, using modularity patterns for internal structure.

He critiqued layered architectures fostering silos, preferring vertical slices for cohesion.

Practical Implementation and Tools

Kirk recommended modular frameworks like OSGi or Jigsaw, but stressed design paradigms over tools. Patterns catalog aids designing evolvable systems.

He concluded: multiple communication levels—classes to services—enhance understanding, urging focus on modularity for adaptive software.

Kirk’s insights reframed architecture as holistic, from code to enterprise, essential for enduring systems.

Links:

• Kirk Knoernschild website
• Gartner website

Lecturer

Alexis Hassler has devoted more than fifteen years to Java development. Operating independently, he engages in programming while also guiding enterprises through training and advisory roles to refine their Java-based workflows and deployment strategies. As co-leader of the Lyon Java User Group, he plays a pivotal part in orchestrating community gatherings, including the acclaimed annual Mix-IT conference held in Lyon.

Abstract

Alexis Hassler meticulously examines the enduring complexities surrounding Java’s classpath and classloading mechanisms, drawing a sharp contrast between conventional hierarchical approaches and the rise of sophisticated modular frameworks. By weaving historical insights with hands-on illustrations and deep integration of JBoss Modules, he unravels the intricacies of dependency clashes, application isolation techniques, and viable transition pathways. The exploration extends to profound consequences for application server environments, delivering practical remedies to alleviate classpath-induced frustrations while casting an anticipatory gaze toward the transformative potential of Jigsaw.

Tracing the Roots: Classloaders and the Enduring Classpath Conundrum

Hassler opens by invoking Mark Reinhold’s bold 2009 JavaOne proclamation that the classpath’s demise was imminent, a statement that fueled expectations of modular systems seamlessly resolving all dependency conflicts. Despite the passage of four years, the classpath remains a fixture within the JDK and application server landscapes, underscoring its stubborn resilience.

Within the JDK, classloaders operate through a delegation hierarchy: the Bootstrap classloader handles foundational rt.jar components, the Extension classloader manages optional javax packages, and the Application classloader oversees user-defined code. This parent-first delegation model effectively safeguards core class integrity yet frequently precipitates version mismatches when disparate libraries demand conflicting implementations.

Hassler vividly demonstrates notorious pitfalls, such as the perplexing ClassNotFoundException that arises despite a JAR’s presence in the classpath or the insidious NoDefClassError triggered by incompatible transitive dependencies. These issues originate from the classpath’s flat aggregation paradigm, which indiscriminately merges all artifacts without regard for scoping or versioning nuances.

Hierarchical Containment Strategies in Application Servers: The Tomcat Paradigm

Application servers like Tomcat invert the delegation flow to enforce robust isolation among deployed artifacts. The WebappClassLoader prioritizes local resources before escalating unresolved requests to parent loaders, thereby permitting each web application to maintain its own dependency ecosystem.

This inverted hierarchy facilitates per-application versioning, substantially mitigating library collisions. Hassler delineates Tomcat’s layered loader architecture, encompassing common, server, shared, and per-webapp classloaders, each serving distinct scoping responsibilities.

Nevertheless, memory leaks persist as a formidable challenge, particularly during hot redeployments when static fields retain references to obsolete classes, inflating PermGen space. Mitigation demands meticulous resource cleanup through context listeners and disciplined finalization practices.

Modular Paradigms on the Horizon: OSGi, Jigsaw, and the Pragmatism of JBoss Modules

OSGi introduces the concept of bundles equipped with explicit import and export declarations, complete with version range specifications. This dynamic loading and unloading capability proves ideal for plugin architectures, though it necessitates substantial refactoring of existing codebases.

Project Jigsaw, slated for Java 9, aspires to embed modularity natively through module declarations that articulate precise dependencies. Despite repeated delays, its eventual integration promises standardized resolution, yet its absence compels interim solutions.

JBoss Modules, already battle-tested within JBoss AS7, employs a dependency graph resolution mechanism. Modules are defined with dedicated resource paths and dependency linkages, enabling parallel coexistence of multiple library versions. Hassler elucidates a module descriptor:

<module xmlns="urn:jboss:module:1.1" name="com.example.app">
    <resources>
        <resource-root path="app.jar"/>
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="org.hibernate" slot="4.3"/>
    </dependencies>
</module>

This structure empowers fine-grained version isolation, exemplified by simultaneous deployment of Hibernate 3 and 4 instances.

Hands-On Deployment Scenarios: JBoss Modules in Standalone and Tomcat Environments

Within JBoss AS7, modules reside in a dedicated directory structure, and applications declare dependencies via jboss-deployment-structure.xml manifests. Standalone execution leverages module-aware classloaders, either through MANIFEST entries or programmatic instantiation.

Hassler showcases a proof-of-concept integration with Tomcat, wherein a custom ClassLoader delegates to JBoss Modules, thereby endowing legacy web containers with modern dependency management. The prototype, available on GitHub, acknowledges limitations in hot-redeployment memory cleanup but validates conceptual soundness.

This adaptability extends modular benefits to environments traditionally tethered to classpath constraints.

Forward-Looking Consequences for Java Ecosystems: Transition Pathways and Jigsaw’s Promise

Classpath tribulations exact a heavy toll on developer productivity, manifesting in protracted debugging sessions and fragile builds. Modular frameworks counter these by enhancing maintainability, accelerating startup through lazy initialization, and fortifying deployment reliability.

Migration hurdles encompass tooling maturity and knowledge gaps, yet the advantages—conflict elimination, streamlined packaging—outweigh transitional friction. Hassler advocates incremental adoption, leveraging JBoss Modules as a bridge to Jigsaw’s eventual standardization.

In conclusion, while the classpath lingers, modular evolution heralds its obsolescence, equipping practitioners with robust tools to transcend historical limitations.

Links:

• Video of the lecture

Mathieu Ancelin and Matthieu Clochard, software engineers at SERLI specializing in Java EE and modular systems, showcased the synergy between CDI, OSGi, and Weld in their Weld-OSGi framework during DevoxxBE2012. Mathieu, a member of the CDI 1.1 expert group and contributor to projects like GlassFish, collaborated with Matthieu, who focuses on OSGi integrations, to demonstrate how Weld-OSGi simplifies dynamic application assembly without added complexity.

They started with CDI basics, where dependency injection manages component lifecycles via annotations like @Inject. OSGi’s modularity, with bundles as deployment units and a dynamic service registry, complements this by allowing runtime changes. Weld-OSGi bridges them, enabling CDI beans to interact seamlessly with OSGi services.

A demo illustrated bootstrapping Weld-OSGi in an OSGi environment, registering bundles, and using extensions for event handling. They emphasized transparent service interactions, where CDI observes OSGi events for dynamic updates.

Mathieu and Matthieu highlighted Weld-OSGi’s role in making OSGi accessible, countering perceptions of its difficulty by leveraging CDI’s programming model.

Fundamentals of CDI and OSGi Integration

Mathieu explained CDI’s bean management, scopes, and qualifiers for precise injections. Matthieu detailed OSGi’s bundle lifecycle and service registry, where services publish and consume dynamically.

Weld-OSGi embeds CDI containers in OSGi, using extensions to observe bundle events and register services as beans. This allows injecting OSGi services into CDI components effortlessly.

Dynamic Features and Practical Demonstrations

They demonstrated service dynamism: publishing a service updates dependent beans automatically. Unpublishing triggers alternatives or errors, ensuring robustness.

Demos included hybrid applications where Java EE components interact with OSGi bundles via the registry, deploying parts dynamically without restarts.

Future Prospects and Community Engagement

Mathieu discussed ongoing work for hybrid servers like GlassFish, embedding Weld-OSGi for cleaner integrations. They referenced RFC 146, inspired by Weld-OSGi, for native CDI-OSGi support.

Encouraging trials, they pointed to GitHub repositories with examples and documentation, fostering feedback to evolve the framework.

Mathieu and Matthieu’s presentation illustrated Weld-OSGi’s potential to create fully dynamic modular applications, blending CDI’s elegance with OSGi’s power.

Links:

• Mathieu Ancelin on LinkedIn
• SERLI on LinkedIn

JOnAS 4 (and older) and JProfiler 4 (and older) were used to working smoothly. JOnAS 5 makes a large use of OSGi libraries… which may “blind” JProfiler.

Here is a workaround, slightly different from former version, to bypass this issue, in order to make JProfiler 5 work with JOnAS 5:

• let’s assume you have installed JOnAS in a folder, let’s say JONAS_ROOT
• install JProfiler 5 with default options, set the JDK, licence key, etc., let’s say in a folder C:\win32app\jprofiler5\ also known as JPROFILER_HOME.
• edit %JONAS_ROOT%/bin/setEnv.bat:
  • set: JAVA_OPTS=-agentlib:jprofilerti=port=8849 "-Xbootclasspath/a:C:\win32app\jprofiler5\bin\agent.jar" %JAVA_OPTS%
• edit %JONAS_ROOT%/conf/osgi/default.properties
  • in the property bootdelegation-packages, add the JProfiler packages:

[java]
bootdelegation-packages com.sun.corba, \
com.sun.corba.*, \
(…)
com.jprofiler, \
com.jprofiler.*, \
com.jprofiler.agent, \
com.jprofiler.agent.*[/java]

• add JPROFILER_HOME\bin\windows to your environment variable PATH.
• startup JOnAS, you should see the following block in standard output:

[java]JProfiler> Protocol version 25
JProfiler> Using JVMTI
JProfiler> 32-bit library
JProfiler> Listening on port: 8849.
JProfiler> Native library initialized
JProfiler> Waiting for a connection from the JProfiler GUI …
JProfiler> Using dynamic instrumentation
JProfiler> Time measurement: elapsed time
JProfiler> CPU profiling enabled
JProfiler> Hotspot compiler enabled
JProfiler> Starting org/ow2/jonas/commands/admin/ClientAdmin …[/java]

• run JProfiler, follow the wizard, take caution to set JProfiler port at 8849 (or remain consistent with the port set in JOnAS config file)

Case:

On launching Eclipse 3.6.1 under Linux 64bits, I get the following error:

[java]Locking is not possible in the directory "/opt/eclipse/configuration/org.eclipse.osgi". A common reason is that the file system or Runtime Environment does not support file locking for that location. Please choose a different location, or disable file locking passing "-Dosgi.locking=none" as a VM argument. /opt/eclipse/configuration/org.eclipse.osgi/.manager/.fileTableLock (Permission denied)[/java]

Fix:

Edit /opt/eclipse/eclipse.ini, add or move the line:

[java]-Dosgi.locking=none[/java]

at the end of the file, or at least after the argument -vmargs

Recent history

BEA WebLogic 9.0, 9.1 and 9.2 were released from 2007: the main features were: a new console, WLST (WebLogic ScriptingTool), deployment plans, WebLogic Diagnostic Framework (WLDF), new security providers (RDBMS, SAML 1.1, etc.), JMS performance improvements, support of Java EE 4, JDK 5, Spring, OpenJPA, Kodo, etc.

Since this date, some events happened:

• Oracle bought Sun (2009)
• Oracle released WebLogic 10.3 (2008)
• Oracle bought BEA (2008)

WebLogic Server 10 General Features

• Developer productivity ehancements
  • JDK 6, Java EE 5
  • Support of EJB3 and JPA
  • BEA enhancements
• Web Services: more annotations, less XML
  • JAX-RPC Web Services Enhancements
  • JAX-WS 2.0 Web Services Implementation
• Misc:
  • Better administration console
  • Auto-Record of Admin Console actions as WLST scripts
  • Automatic JTA Transaction Recovery Service (TRS) migration
  • SNMP 3.0
  • Production Application Redeployment enhancements
  • Clustering – Unicast messaging (in addition to Multicast)

Programmer Perspective

• New persistence engine: TopLink
• OEPE (Oracle Entreprise Pack for Eclipse): sequence of tools and plugins for Eclipse: remote deployment, debugging,  editors for weblogic.xml and weblogic-application.xml, wizards, facets, Weblogic ClientGen, WSDLC and JAXB wizards
• Optimizations for Spring integration and certication
• Web 2.0:
  • Ajax / Dojo client support
  • Http publish / submit engine for collaborative applications:
    • Bayeux protocol
    • data exchange within applications over persistent connections
    • scalability for Dojo clients
• Ad-hoc tools for:
  • Oracle Database
  • Spring
  • JAX-WS webservices

Lightweight WebLogic Server

WebLogic 10 offers a light weight server:

• Install only “core” WebLogic server
• Optionally, startup other services (JDBC, EJB, JMS, etc.)
• FastSwap: modify classes without requiring redeployment.

Architect Perspective

Architects have to consider WebLogic as a complete suite, and not only WebLogic Server:

• Oracle RAC integration: Connectivity to RAC with load balancing, failover, transactions
• Enterprise Messaging with JMS: High performance and reliable JMS messaging engine “built-in”
• ActiveCache with Coherence*Web and EJB/JPA: Coherence Data Grid caching included and integrated
• Operations Automation: Tools for automating management of applications and servers
• Operations Insight: Tools for diagnosing problems in development and production
• Other features
  • Development tools: Choice of tools for developer productivity
  • Web Services: Enterprise Web Services for SOA
  • TopLink: Persist application data to stores with performance and productivity. It works in a way similar to Hibernate L2 cache.
  • Spring: Enable flexible choice of dev frameworks with same WebLogic QOS

Production and Support Perspective

WebLogic 10 provides a tool: JRockit Mission Control

• monitors more than 150 parameters:
• CPU
  • memory
  • leaks
  • latency spikes
  • threads
  • object references
  • JDBC connections
  • JMS
  • pools
  • clusters
  • configuration files
  • etc.
• allows to compare WebLogic domains
• Runtime Analyzer: runtime capture for offline analysis, Garbage Collector analysis, etc.

Coherence – ActiveCache

Coherence is the Data Grid offered by Oracle. It allows to store Java objects in memory, and share them between all instances. From a certain viewpoint, Coherence looks like the GigaSpaces.

Roadmap for Future WebLogic Releases

• Support of Java EE 6 (ratified by the community in last December)
• OSGi deployment
• More native integration for WebLogic Server – Coherence – Oracle Database
• JRockit Flight Recorder for constant record
• Virtualization
• More integration with Maven, Hudson and Cruise Control
• Shared Library: use the same JAR for many applications, rather than packing the same JAR in different EARs.
• On long term:
  • IDE
    • NetBeans to be oriented onto J2ME development
    • JDevelopper to remain Oracle strategic IDE
    • Contributions to Eclipse to go on
  • JRockit and Sun HotSpot JVMs to be merged.