dotCMS / core

Headless/Hybrid Content Management System for Enterprises
http://dotcms.com
Other
845 stars 465 forks source link

Enable CDI : Timebox - Check if existing work can be easily merged now #29552

Closed spbolton closed 3 days ago

spbolton commented 1 month ago

Create branch based upon https://github.com/dotCMS/core/tree/steve-poc-add-cdi

Thorough testing of existing code and endpoints

fabrizzio-dotCMS commented 2 weeks ago

Note to QA: We upgraded to a more recent version of Jersey for this task, specifically 2.28. This update introduced some issues that were subsequently resolved. For instance, form validation in the /api/environment endpoint stopped functioning correctly; the response lost its JSON format and started being returned as plain text. This issue was successfully addressed.

However, it would be a good idea to test other endpoints that perform similar validation, such as:

The secret creation endpoints. Test by sending both valid and invalid values, and verify against previous versions of the endpoints: POST: /v1/apps/{key}/{siteId} POST: /v2/languages/ Additionally, we need to test loading dynamic plugins that deploy a new REST endpoint.

We now have a JerseyApplicationEventListener class that allows us to track the loaded resources. It can be used alongside the previous code to generate a list comparing the current resources with the expected ones, helping to detect if something is missing or if there are any extra resources.

Regarding CDI: to test CDI integration Here's a starting point in the class: com/dotcms/cdi/CDIUtils.java There is an example in src/test/java/com/dotcms/cdi/SimpleInjectionIT.java There's another example of the actual working code in the DotRestApplication Where there is a Singleton that used to be created manually and got replaced by injection using the Annotation @ApplicationScope Please note that @Singleton isn't going to work Here's why https://stackoverflow.com/questions/44097337/how-to-make-a-singleton-in-cdi-1-2 I decided to leave it out since we pretty much can accomplish the same with @ApplicationScope

So we should limit to https://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_defining_annotations

Here's an interesting pattern that uses Weld on a StandAlone App

public class Main {

    public static void main(String[] args) {
        Weld weld = new Weld();
        try (WeldContainer container = weld.initialize()) {
            // Doing this 
            MyApplication app = container.select(MyApplication.class).get();
            app.run();
         }

           //Is Equivalent to doing this :
            final MyApplication myApplication = CDI.current().select(MyApplication.class).get();
            myApplication.run();

           //So on a Web Application where we aren't supposed to have direct access to the Weld Container 
           //We should do the later 

           // This could easily be our entry Point class that Injects all the services etc..  
           // At some point, we could do this to our APILocator so all new services will get CDI            
           //for now I would recommend we use a Class to serve as the locator of our new API and do that initialization there 

    }
}
jgambarios commented 3 days ago

While working on the new job queue system I was able to validate CDI is working correctly.