Jonathan Lalou's Blog

Posts Tagged ‘AlexisHassler’

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

Lecturer

Alexis Hassler is a Java developer with over fifteen years of experience. He operates as an independent professional, engaging in coding, training, and supporting enterprises to enhance their Java development and deployment practices. As co-leader of the Lyon Java User Group, he contributes to community events like the Mix-IT conference in Lyon.

Abstract

Alexis Hassler’s session explores Arquillian’s capabilities for testing web applications, extending beyond Java EE components to comprehensive integration testing. Demonstrating extensions like Drone, Graphene, and Warp, he illustrates client-side and server-side testing methodologies. The discussion analyzes setup, execution, and benefits, emphasizing real-world testing that verifies both client interactions and server states for robust applications.

Core Concepts of Arquillian: Integration Testing Reversed

Hassler introduces Arquillian as a tool for integration testing Java EE components, defining a component as an entity like an EJB with injected dependencies, transactional, and security contexts. Unlike embedding containers in tests, Arquillian packages the component with tests and deploys to a container, inverting the process for realistic environments.

A basic test class uses JUnit with an Arquillian runner. The @Deployment annotation creates a testable archive (e.g., WAR) containing classes and resources. Methods like @Test execute within the container, accessing injected resources seamlessly.

This approach ensures tests run in production-like settings, catching issues early. Hassler contrasts with traditional unit tests, highlighting Arquillian’s focus on integrated behaviors.

Extending to Web Testing: Drone and Graphene for Client-Side Interactions

For web applications, Hassler leverages Drone and Graphene extensions, combining Arquillian’s deployment with Selenium’s browser automation. Drone instantiates WebDriver instances; Graphene enhances with guards for AJAX handling.

In setup, specify a managed container like JBoss AS in arquillian.xml. Tests deploy the app, then use @Drone-annotated browsers to interact: navigate via @ArquillianResource URLs, fill forms, assert outcomes.

Graphene’s guards wait for requests, ensuring reliable tests amid asynchronous behaviors. This client-mode testing (@RunAsClient) simulates user interactions, verifying HTTP responses without server-side access.

Code example:

@Drone
WebDriver browser;

@ArquillianResource
URL deploymentUrl;

@Test
@RunAsClient
public void testLogin() {
    browser.get(deploymentUrl + "login.jsf");
    // Interact and assert
}

This deploys, browses, and validates, bridging unit and functional testing.

Advanced Verification with Warp: Bridging Client and Server States

To inspect server-side states during client tests, Hassler introduces Warp. It wraps requests with payloads, executing inspections on the server before/after phases.

Define inspections extending WarpInspection, annotating with @WarpTest. Use @BeforeServlet/@AfterServlet for timing. Deploy via @WarpDeployment.

Example: Verify session attributes post-login. Client triggers action; Warp asserts server-side.

public class SessionInspection extends WarpInspection {
    @AfterServlet
    public void checkSession() {
        // Assert session values
    }
}

Warp enables “real tests” by combining client simulations with server validations, detecting mismatches invisible to pure client tests.

Hassler notes Warp’s alpha status, advising community forums for issues.

Implications for Development Practices: Flexibility and Community Support

Arquillian’s modularity allows mixing modes: @RunAsClient for web, in-container for components. This flexibility suits diverse apps, from simple servlets to complex JSF.

Challenges include initial setup—choosing extensions, versions, resolving conflicts. Documentation is evolving; forums on JBoss.org are responsive, often from developers.

Hassler encourages adoption for effective testing, reducing deployment surprises. Community involvement accelerates learning, fostering better practices.

In essence, Arquillian with extensions empowers thorough, efficient web testing, aligning development with production realities.

Links:

• Video of the lecture
• Alexis Hassler on LinkedIn