DEV Community: Muhammed DURRA

If Injection

Muhammed DURRA — Thu, 31 Dec 2020 09:17:36 +0000

Hackers use 𝗦𝗤𝗟 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻 to destroy the database
Developers use 𝗜𝗳 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻 to destroy the code :D

Practical Java15 sealed interfaces with design patterns

Muhammed DURRA — Tue, 24 Nov 2020 17:44:26 +0000

As a quick review of template method and chain of responsibility patterns we can define a template of the chain (no to have a broken chain) with an abstract class:

abstract class MiddlewareBase {
    static MiddlewareBase of(MiddlewareBase... middlewares) {
        for (int i = 0; i < middlewares.length - 1; i++) {
            middlewares[i].setNext(middlewares[i + 1]);
        }
        return middlewares[0];
    }
    private MiddlewareBase next;
    public void setNext(MiddlewareBase next) {
        this.next = next;
    }
    public final void check(Request request) {
        checkInternal(request);
        if (next != null) {
            next.checkInternal(request);
        }
    }
    abstract void checkInternal(Request request);
}

Until now this is good and seems perfect, now to add more abstraction and to achieve the program to interface not implementation simple principle let us define the Middleware interface to represent our chain from interface perspective

interface Middleware {
    void check(Request request);
}

then we can re-write our MiddlewareBase as

abstract class MiddlewareBase implements Middleware {
    static Middleware of(MiddlewareBase... middlewares) {
        for (int i = 0; i < middlewares.length - 1; i++) {
            middlewares[i].setNext(middlewares[i + 1]);
        }
        return middlewares[0];
    }
    private MiddlewareBase next;
    public void setNext(MiddlewareBase next) {
        this.next = next;
    }
    public final void check(Request request) {
        checkInternal(request);
        if (next != null) {
            next.checkInternal(request);
        }
    }
    abstract void checkInternal(Request request);
}

with this and the two following simple examples of Middleware

class CsrfMiddleware extends MiddlewareBase {
    @Override
    void checkInternal(Request request) {
        System.out.println("csrf check");
    }
}
class XssMiddleware extends MiddlewareBase {
    @Override
    void checkInternal(Request request) {
        System.out.println("xss check");
    }
}

we can define and use our middleware chain like

Middleware middleware = MiddlewareBase.of(new CsrfMiddleware(), 
                                        new XssMiddleware());
middleware.check(new Request());

but nothing can prevent others from implementing the Middleware interface and break the chain implementation.
— — — — — —
Starting from version 15 and as a preview feature JDK presented the sealed class/interface feature to restrict which other classes or interfaces may extend or implement them.
we can define a sealed interface/class with sealed modifier, Then, after any extends and implements clauses, the permits clause specifies the classes that are permitted to extend the sealed class.

sealed interface Handler permits HandlerTemplate {
  void handle(Handleable handleable);
}

with this definition no class except HandlerTemplate can implement the Handler interface.
Let us now redefine the Middleware example with sealed interface so no one can implement it and break the main purpose of it as a CoR implementation.

sealed interface Middleware permits MiddlewareBase {
    void check(Request request);
}

The MiddlewareBase class will have no change except adding non-sealed modifier which means no restriction on implementation classes

abstract non-sealed class MiddlewareBase implements Middleware {
...
}

Also CsrfMiddleware and XssMiddleware will not change.
now if we tried to create another implementation of Middleware compiler will fail complaining: class is not allowed to extend sealed class: Middleware or with an IDE like intellij we get directly.

sealed classes/interfaces have many useful usecases and eventought it is new -still in preview- in Java it is presented in other languages like Kotlin (only sealed classes) and Scala (sealed trait) with different intents.
I approached the sealed interfaces with core design principles and patterns to express the fact that the richer the language features the better design we get, comments are welcomed.

Spring Stereotypes

Muhammed DURRA — Thu, 23 Jul 2020 10:20:02 +0000

Spring stereotype annotations are aliases for @Component annotation, like Service, Repository and Controller.
Hence you can define your own stereotype and customize it like the Api component here and spring container will take the rest on initializing the suitable component.

Inheritance without extends

Muhammed DURRA — Sun, 26 May 2019 00:47:23 +0000

Yes, inheritance means adding or changing the behavior of a class by a sub class
the traditional way of doing inheritance is by extending a class adding new methods.
Let us take an example from Java world

Super class

extending this class to add a new behavior can be done directly and easily:

Inherited

nice !

But here the inheritance is static, I need to create a new class for every new functionality.
Another way of adding functionality come from Design Patterns world, it is
the Visitor Pattern which basically “represents an operation to be performed on the elements of an object structure.” but also can be utilized to define a new operation without changing the class.
One mandatory pre-requirement for this pattern is to implement it :), the implementation is adding a behavior to the class to accept the Visitor.

Visitor

Visitor is an interface with single (or multiple) method(s)

Visitor Interface

Let us implement the Sub class simulator ->

Visitor Implementation

But we had to add a new class for the new functionality! , Yes, but the good thing is that we can add the functionality dynamically to single objects of the class (the same idea applied in Decorator Pattern)

Visitor Tester

adding another Visitor with lambda expressions

Using Lambda

A full snippet

This will not give a full control and capabilities of traditional inheritance but it helps :)

As a final note: try to support visitor pattern whenever possible in your classes :)

all comments are welcomed.

Deployment of EJB server application and client independently

Muhammed DURRA — Sun, 26 May 2019 00:18:02 +0000

A friend asked me to work on an EJB and EJB client project in an independent separated deployment package for each.

I get used to use Netbeans to do that along time ago, but I decided to do it with maven. Looking for that I found that Apache provided plugins of EAR and EJB application for maven:
https://maven.apache.org/plugins/maven-ear-plugin/ for deploying artifacts as a Java EE Enterprise Archive (EAR)
https://maven.apache.org/plugins/maven-ejb-plugin/ which generates Java Enterprise JavaBean (EJB) file as well as the associated client jar.
That was almost perfect though the documentation was not clear enough. then I looked for someone how used it and fortunately I found an example on github, it was good to some extent, but wasn’t organized well and I had build issues with maven.

Making some efforts to re-organize the pom structure and fix some configurations I was able to build the EJB application as an isolated EAR file (because of dependencies on Hibernate it should be EAR not JAR).
the plugin also generates EJB jar and EJB client jar for you and with maven you can add it easily as a dependency for your client application.

The build of the EJB client application was straightforward with JSF, primefaces and the created EJB client jar built in the first step. then I used Glassfish server to deploy both artifacts.

This was just a simple try to build isolated Enterprise Java applications but things may go complex with other requirements.

You can check github for sources and build/deploy instructions
https://github.com/mhddurrah/ejb-application
https://github.com/mhddurrah/ejb-jsf-client
and don’t hesitate to contact me for updates or other issues/ queries.