Giter VIP home page Giter VIP logo

susel's Introduction

CircleCI

Susel

Super Service Loader: Super charge the module aware service loader in Java 11. Susel is a light weight library that helps one build Java module system native applications.

Introduction

Service loader mechanism of Java, introduced in Java 6 and revised in Java 9, is used to locate and load services. A service is a well known interface or class (usually abstract). A service provider is a concrete implementation of a service. The ServiceLoader class is a facility to load service providers that implement a given service. A Java native module can declare that it uses a specific service in its module description (module-info.java). The module can then use the ServiceLoader to locate and load the service providers deployed in the run time environment.

Susel builds on this service loading mechanism and provides a few useful features. Susel enables you to specify required or optional service references (through annotations) that a a given service provider might need to operate. Partly inspired by OSGI, Susel provides an "activate" annotation that can be used by a service provider to do some initiation work or to read configuration from a global context map passed to it by Susel.

Basic Usage

If you are using a build tool like Maven or Gradle, add the following dependency to access Susel API:

  • Maven pom.xml

     <dependency>
       <groupId>io.github.udaychandra.susel</groupId>
       <artifactId>susel</artifactId>
       <version>0.1.2</version>
     </dependency>
  • Gradle build.gradle

     dependencies {
       compile 'io.github.udaychandra.susel:susel:0.1.2'
     }

Note that Susel requires Java 11

Begin by defining a service interface.

package com.example.svc;

public interface HelloService {
    String hello(String id);
}

Create a service provider by implementing the service interface.

package com.example.svc.name;

public class HelloNameService implements HelloService {
    private UserService userService;
    
    @ServiceReference(cardinality = Cardinality.ONE)
    public void setUserService(UserService userService) {
        this.userService = userService;
    }
    
    public String hello(String id) {
        return "Hello " + userService.getName(id);
    }
}

Update the module descriptor (module-info.java)

module com.example.svc.name {
    exports com.example.svc.name;

    requires com.example.svc;

    provides com.example.svc.HelloService 
        with com.example.svc.name.HelloNameService;
}

Now, a consuming client of the service interface can delegate the lookup, preparation and loading to Susel. Say the module descriptor of the client looks something like this:

module com.example.client {
    exports com.example.client;

    requires com.example.svc;
    requires io.github.udaychandra.susel;

    uses com.example.svc.HelloService;
}

The client can then activate Susel once and start loading services. For example, to load the HelloService one can do this in the application's main method:

Susel.activate(Map.of());
var helloService = Susel.get(HelloService.class);

Susel will take care of loading a service provider that implements the hello service. When it finds the HelloNameService, it will ensure that at least one service provider that implements the required UserService reference is found and injected, activates HelloNameService and returns the now ready to use HelloNameService.

Susel relies on the presence of a metadata file (META-INF/susel.metadata) in a module to figure out the service references used by a service provider, their cardinalities and the method that should be invoked to activate the service provider. This metadata file should be generated during compile time.

There's a gradle plugin that can automate the generation and packaging of these metadata files. The plugin calls the Susel tool which can be manually invoked as well.

A maven plugin is in the works

Development

This is a community project. All contributions are welcome.

To start contributing, do the following:

  • Install JDK 11
  • Fork or clone the source code
  • Run the build using the gradle wrapper
gradlew clean build

License

Apache License 2.0

susel's People

Contributors

udaychandra avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

susel's Issues

Exemplify "boilerplate code" issue solved by Susel

I am studing for 1Z0-815 and I am trying to understand ServiceLoader. Honestly, I haven't use it yet in real scenarios. I was reading https://www.infoq.com/articles/java11-aware-service-module/ and I was really getting the point until I reached:

..." So far so good, but when we start to implement a full-blown system using this new services mechanism, we will soon realize that we have to write boilerplate code each time we need to locate and load a service. It gets more tedious and a tad more complex when we have to run some initialization logic each time we load a service provider.

A typical thing to do is to refactor the boilerplate code into a utility class and add it as part of a common module shared by other modules in our application. While that’s a good first step, due to the strong encapsulation and reliable configuration guarantees provided by the Java module system, our utility method will fail to use the ServiceLoader class and load services.

Since the common module has no knowledge of the given service interface and since it doesn’t include the “uses” clause in its module descriptor, the ServiceLoader cannot locate providers that implement the service interface even though they might be present on the module path. Not only that, but if you add the “uses” clause to the common module descriptor, it defeats the purpose of encapsulation and worse, introduces circular dependency...."

As far as I understood, Susel was mainly created to avoid "utility method will fail to use the ServiceLoader class and load services." when we code a common module vecause "ServiceLoader cannot locate providers that implement the service interface". Now I really got confused. Kindly, can you exemplify? It wouldn't be easily fix by "include the “uses” clause in its module descriptor"?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.