John's Technical Blog

Dynamically Registering Service Classes in Laravel 10

2023-08-03

Introduction

In the process of migrating a proprietary PHP application to the Laravel 10 framework, I faced an interesting challenge. The application I was working on had 44 service classes. In Laravel, service classes are typically registered manually in the AppServiceProvider.php file. However, the thought of manually registering all these services seemed daunting and inefficient. Plus, it would be a hassle to update the AppServiceProvider.php every time a service is added, renamed, or removed. Therefore, I decided to find a way to register these service classes dynamically. This post outlines the solution I came up with.

Problem Statement

When migrating a large PHP application into Laravel, manually registering a large number of service classes is not only tedious but also prone to errors. Moreover, it's not scalable: every time we add, rename, or remove a service, we need to manually update the AppServiceProvider.php file. We need a solution that allows us to dynamically register all service classes in the application and automatically adjust when changes are made.

Solution

The solution I came up with involves using Laravel's File::allFiles() method to get all PHP files in the service classes directory and then dynamically register these classes in the AppServiceProvider.php file. The service classes are registered using Laravel's service container, which allows Laravel to automatically resolve these classes when they're needed in other parts of the application.

Here is a code snippet used to find all the classes in any package. I happen to have it in a class called ClassUtil:



/**
 * This method is used to recursively retrieve all the classes within a package that have been configured in the Composer autoloader.
 *
 * @param string $package The package name
 *
 * @return string[] The classes
 */
public function getPackageClasses(string $package): array
{
    /* Get all PHP files in the package directory */
    try {
        $basePath = base_path($package);
        $files = File::allFiles($basePath);
    } catch (Exception) {
        /* Catches the case where the default Laravel "App" package resides in the "app" folder and the server is case-sensitive. */
        $basePath = base_path(lcfirst($package));
        $files = File::allFiles($basePath);
    }
    error_log($basePath);

    $rootPath = str_replace(str_replace('/', DIRECTORY_SEPARATOR, $package), '', $basePath);

    $classes = [];
    foreach ($files as $file) {
        /* Convert the file path to a namespaced class name */
        $class = str_replace(
            ['/', '.php'],
            ['\\', ''],
            Str::after($file->getRealPath(), $rootPath)
        );

        /* Check if the class exists and is not abstract */
        if (class_exists($class) && !(new ReflectionClass($class))->isAbstract()) {
            $classes[] = $class;
        }
    }

    return $classes;
}

And this is how I use it in AppServiceProvider.php:


/**
 * Register any application services.
 *
 * @return void
 */
public function register(): void
{
    parent::register();
    foreach ((new ClassUtil())->getPackageClasses('App/Services') as $class) {
        $this->app->singleton($class, function () use ($class) {
            return new $class();
        });
    }
}

Benefits

This technique has several benefits:

  • Simplicity: It saves us the trouble of manually registering each service class.
  • Scalability: It allows us to easily add, rename, or remove services without having to manually update the AppServiceProvider.php file.
  • Flexibility: It provides a flexible way of managing service classes, especially in large applications.

Conclusion

Dynamically registering service classes in Laravel is a handy trick that can save you a lot of time and effort, especially when dealing with large applications. I hope this post helps you in your Laravel development journey. If you have any questions or comments, feel free to leave them below!

Dynamically Registering Service Classes in Laravel 10

2023-08-03

Introduction

In the process of migrating a proprietary PHP application to the Laravel 10 framework, I faced an interesting challenge. The application I was working on had 44 service classes. In Laravel, service classes are typically registered manually in the AppServiceProvider.php file. However, the thought of manually registering all these services seemed daunting and inefficient. Plus, it would be a hassle to update the AppServiceProvider.php every time a service is added, renamed, or removed. Therefore, I decided to find a way to register these service classes dynamically. This post outlines the solution I came up with.

Problem Statement

When migrating a large PHP application into Laravel, manually registering a large number of service classes is not only tedious but also prone to errors. Moreover, it's not scalable: every time we add, rename, or remove a service, we need to manually update the AppServiceProvider.php file. We need a solution that allows us to dynamically register all service classes in the application and automatically adjust when changes are made.

Solution

The solution I came up with involves using Laravel's File::allFiles() method to get all PHP files in the service classes directory and then dynamically register these classes in the AppServiceProvider.php file. The service classes are registered using Laravel's service container, which allows Laravel to automatically resolve these classes when they're needed in other parts of the application.

Here is a code snippet used to find all the classes in any package. I happen to have it in a class called ClassUtil:



/**
 * This method is used to recursively retrieve all the classes within a package that have been configured in the Composer autoloader.
 *
 * @param string $package The package name
 *
 * @return string[] The classes
 */
public function getPackageClasses(string $package): array
{
    /* Get all PHP files in the package directory */
    try {
        $basePath = base_path($package);
        $files = File::allFiles($basePath);
    } catch (Exception) {
        /* Catches the case where the default Laravel "App" package resides in the "app" folder and the server is case-sensitive. */
        $basePath = base_path(lcfirst($package));
        $files = File::allFiles($basePath);
    }
    error_log($basePath);

    $rootPath = str_replace(str_replace('/', DIRECTORY_SEPARATOR, $package), '', $basePath);

    $classes = [];
    foreach ($files as $file) {
        /* Convert the file path to a namespaced class name */
        $class = str_replace(
            ['/', '.php'],
            ['\\', ''],
            Str::after($file->getRealPath(), $rootPath)
        );

        /* Check if the class exists and is not abstract */
        if (class_exists($class) && !(new ReflectionClass($class))->isAbstract()) {
            $classes[] = $class;
        }
    }

    return $classes;
}

And this is how I use it in AppServiceProvider.php:


/**
 * Register any application services.
 *
 * @return void
 */
public function register(): void
{
    parent::register();
    foreach ((new ClassUtil())->getPackageClasses('App/Services') as $class) {
        $this->app->singleton($class, function () use ($class) {
            return new $class();
        });
    }
}

Benefits

This technique has several benefits:

  • Simplicity: It saves us the trouble of manually registering each service class.
  • Scalability: It allows us to easily add, rename, or remove services without having to manually update the AppServiceProvider.php file.
  • Flexibility: It provides a flexible way of managing service classes, especially in large applications.

Conclusion

Dynamically registering service classes in Laravel is a handy trick that can save you a lot of time and effort, especially when dealing with large applications. I hope this post helps you in your Laravel development journey. If you have any questions or comments, feel free to leave them below!

Creating and Nesting SimpleXMLElement Objects in PHP

2023-06-15

Introduction

When working with XML data in PHP, the SimpleXMLElement class provides a convenient way to create and manipulate XML structures. One common requirement is to create a SimpleXMLElement and add it as a child to another SimpleXMLElement. In this blog post, we'll explore the correct solution to achieve this.

Creating the Parent and Child Elements

/* Create the parent SimpleXMLElement */
$parent = new SimpleXMLElement('<parent></parent>');

/* Create the child SimpleXMLElement */
$child = new SimpleXMLElement('<child></child>');

Adding Content to the Child Element

$child->addChild('name', 'John');
$child->addChild('age', 25);

Importing and Nesting the Child Element

Now comes the crucial part: importing and nesting the child element within the parent element. We'll use the dom_import_simplexml() function to convert the SimpleXMLElement objects to DOMNode objects. Here's how it's done:

$domChild = dom_import_simplexml($child);
$domParent = dom_import_simplexml($parent);
$domChild = $domParent->ownerDocument->importNode($domChild, true);
$domParent->appendChild($domChild);

In the above code, we import the child element into the parent element's document using the importNode() method. The second argument true indicates that we want to import the entire subtree of the child node.

Printing the Final XML Structure

To see the final XML structure, we can call the asXML() method on the parent element:

echo $parent->asXML();

This will output the complete XML structure, including the parent and nested child elements.

The xmlAdopt() Method

To simplify the process of adopting a child element into a parent element, we can use a helper method called xmlAdopt():

/**
 * Adopt a SimpleXMLElement into another SimpleXMLElement.
 *
 * @param SimpleXMLElement $parent the parent element
 * @param SimpleXMLElement $child  the child element to add to the parent
 */
private function xmlAdopt(SimpleXMLElement $parent, SimpleXMLElement $child): void
{
    $domChild = dom_import_simplexml($child);
    $domParent = dom_import_simplexml($parent);
    $domChild = $domParent->ownerDocument->importNode($domChild, true);
    $domParent->appendChild($domChild);
}

Using the xmlAdopt() Method:

$this->xmlAdopt($parent, $child);

Conclusion:

Creating and nesting SimpleXMLElement objects in PHP requires careful handling

Creating and Nesting SimpleXMLElement Objects in PHP

2023-06-15

Introduction

When working with XML data in PHP, the SimpleXMLElement class provides a convenient way to create and manipulate XML structures. One common requirement is to create a SimpleXMLElement and add it as a child to another SimpleXMLElement. In this blog post, we'll explore the correct solution to achieve this.

Creating the Parent and Child Elements

/* Create the parent SimpleXMLElement */
$parent = new SimpleXMLElement('<parent></parent>');

/* Create the child SimpleXMLElement */
$child = new SimpleXMLElement('<child></child>');

Adding Content to the Child Element

$child->addChild('name', 'John');
$child->addChild('age', 25);

Importing and Nesting the Child Element

Now comes the crucial part: importing and nesting the child element within the parent element. We'll use the dom_import_simplexml() function to convert the SimpleXMLElement objects to DOMNode objects. Here's how it's done:

$domChild = dom_import_simplexml($child);
$domParent = dom_import_simplexml($parent);
$domChild = $domParent->ownerDocument->importNode($domChild, true);
$domParent->appendChild($domChild);

In the above code, we import the child element into the parent element's document using the importNode() method. The second argument true indicates that we want to import the entire subtree of the child node.

Printing the Final XML Structure

To see the final XML structure, we can call the asXML() method on the parent element:

echo $parent->asXML();

This will output the complete XML structure, including the parent and nested child elements.

The xmlAdopt() Method

To simplify the process of adopting a child element into a parent element, we can use a helper method called xmlAdopt():

/**
 * Adopt a SimpleXMLElement into another SimpleXMLElement.
 *
 * @param SimpleXMLElement $parent the parent element
 * @param SimpleXMLElement $child  the child element to add to the parent
 */
private function xmlAdopt(SimpleXMLElement $parent, SimpleXMLElement $child): void
{
    $domChild = dom_import_simplexml($child);
    $domParent = dom_import_simplexml($parent);
    $domChild = $domParent->ownerDocument->importNode($domChild, true);
    $domParent->appendChild($domChild);
}

Using the xmlAdopt() Method:

$this->xmlAdopt($parent, $child);

Conclusion:

Creating and nesting SimpleXMLElement objects in PHP requires careful handling

MySQL AES Encryption in Ruby

2018-05-14

I was asked to find a way to encrypt strings in Ruby that would be compatible with MySQL's AES_ENCRYPT and AES_DECRYPT functions. I found several solutions online, but none of them worked the way I expected. After cobbling together several examples, I finally came up with a solution that proved to be compatible with the MySQL version. This was written for use with Ruby 2.3.5. This module can be used as follows:

MySQL AES Encryption in Ruby

2018-05-14

I was asked to find a way to encrypt strings in Ruby that would be compatible with MySQL's AES_ENCRYPT and AES_DECRYPT functions. I found several solutions online, but none of them worked the way I expected. After cobbling together several examples, I finally came up with a solution that proved to be compatible with the MySQL version. This was written for use with Ruby 2.3.5. This module can be used as follows:
Running a Tomcat-based Spring Boot application in Docker

2018-05-01

In one of the projects I am working on, I was tasked from taking a Tomcat application that ran on an EC2 server, and get it running with the Spring Boot framework in a Docker container. The twist is that the application needed read-write access to the resources folder within the project. In order to do that, the application needed to be run as an "exploded" WAR file (It had been run that way on the old server as well).

I accomplished this with this Docker file:

The WAR file is compiled with the "spring-boot-maven-plugin", and includes all the dependency JARs, so the application can be run stand-alone.

That entry in the POM is:

And the "org.springframework.boot.loader.WarLauncher" Class is what Spring Boot uses to bootstrap the applicatiton on the embedded Tomcat.

Running a Tomcat-based Spring Boot application in Docker

2018-05-01

In one of the projects I am working on, I was tasked from taking a Tomcat application that ran on an EC2 server, and get it running with the Spring Boot framework in a Docker container. The twist is that the application needed read-write access to the resources folder within the project. In order to do that, the application needed to be run as an "exploded" WAR file (It had been run that way on the old server as well).

I accomplished this with this Docker file:

The WAR file is compiled with the "spring-boot-maven-plugin", and includes all the dependency JARs, so the application can be run stand-alone.

That entry in the POM is:

And the "org.springframework.boot.loader.WarLauncher" Class is what Spring Boot uses to bootstrap the applicatiton on the embedded Tomcat.

OpenPojo Java 9 Compatibility Workaround

2017-11-02

I am working on updating applications at work to Java 9. I have been using OpenPojo for years to test all my POJOs in one go. However, I found that the tests started throwing the exception:

java.lang.NoClassDefFoundError: Could not initialize class com.openpojo.reflection.java.packageloader.Package

I traced through the OpenPojo code and found that it was hard coded to read the Java class path from the old "sun.boot.class.path" system property. This property has been completely removed from Java 9, in favor of "java.class.path," which has been available since at least Java 7. (See https://docs.oracle.com/javase/8/docs/technotes/tools/windows/findingclasses.html)

I submitted my findings in an issue for the developers consideration: https://github.com/oshoukry/openpojo/issues/108

In the meantime, I developed the following workaround that can be inserted into a current POJO test class, and will allow the code to function the same way in Java 9.

OpenPojo Java 9 Compatibility Workaround

2017-11-02

I am working on updating applications at work to Java 9. I have been using OpenPojo for years to test all my POJOs in one go. However, I found that the tests started throwing the exception:

java.lang.NoClassDefFoundError: Could not initialize class com.openpojo.reflection.java.packageloader.Package

I traced through the OpenPojo code and found that it was hard coded to read the Java class path from the old "sun.boot.class.path" system property. This property has been completely removed from Java 9, in favor of "java.class.path," which has been available since at least Java 7. (See https://docs.oracle.com/javase/8/docs/technotes/tools/windows/findingclasses.html)

I submitted my findings in an issue for the developers consideration: https://github.com/oshoukry/openpojo/issues/108

In the meantime, I developed the following workaround that can be inserted into a current POJO test class, and will allow the code to function the same way in Java 9.