I'm trying to use Jakarta jnosql Artemis along with a Spring Boot application. Artemis requires a CDI (Context and Dependency Injection) implementation to be provided. Overall, Spring Framework does it, however it implements it's own, similar interface org.springframework.web.SpringServletContainerInitializer, but Artemis seems to require exact implementation of SeContainerInitializer.
Does any class from a Spring ecosystem implement SeContainerInitializer or SeContainer?
or
Is it possible to use Jakarta jnosql Artemis with a Spring Boot application?
If yes - how? A simple example of Spring Boot using Jakarta jnosql Artemis graph to insert and query would be great.
If no - why? Especially, is it a temporary (will Spring implement it in a future) or a permanent state?
I explicitly do not want to use Spring Data.
I am aware, that they do provide a similar solution to Jakarta jnosql Artemis.
Two years ago a similar question was asked [ https://stackoverflow.com/questions/68592784/using-jnosql-cdi-library-with-spring-boot-bean-not-found ], and one of the comments claimed that Spring does not implement that interface. I would like to know if that has changed or is going to change. Answer also suggested Spring Data, which I do not want to use.
I tried setting up a Spring Boot application and using @Inject annotation to inject classes like GraphTemplate (from Artemis). Spring throws an exception, that it is unable to find any bean to inject of that class.
I have also found an application on Github that has a working example of Jakarta jnosql Artemis with Weld (CDI implementation). Then I tries to replace Weld with Spring Boot, however I cannot find an implementation for an interface SeContainer.
Does any class from a Spring ecosystem implement SeContainerInitializer or SeContainer?
No, they won't/can't. Spring is not a CDI implementation. Spring does seem to borrow some CDI interfaces/annotations occasionally, but that does not mean it implements the CDI Specification or could even hope to pass the CDI TCK. While CDI and Spring serve a similar/related purpose, Spring is just its own thing.
Some concepts that exist in CDI don't exist in Spring and vice-versa, for better/worse.
There's a bit of history to this. The idea of Runtime Dependency Injection manifested itself J2EE a long time ago (Late 2000s era). This required Application Server Vendors (like IBM) to implement the specifications in their containers (like WebSphere).
Spring designers were frustrated at the pace of J2EE feature development and created an alternate and different framework called Spring Framework, a full stack enterprise framework. At no point was compatibility with J2EE specifications a concern, although certain parts of Spring could interact with J2EE servers.
Fast forward and that legacy lives on: Spring is it's own framework that does not implement the JavaEE/JakartaEE specification; but Spring can call into parts of it or borrow some of the annotations. But for the most part you can't pull in components designed for CDI into Spring and vice-versa. It's just two different worlds.