Make CDI to replace EJB

[Emily-Jiang]

A frequent request for CDI is to replace EJB as CDI is becoming more and more popular and widely adopted. CDI covers many EJB functionalities with a much easier framework. However, there are some gaps to be filled. I would like to use this issue to address the gaps where CDI has no counterpart functionalities. This includes:

• startup

• Timer
  I think the useful feature of EJB is startup, so in CDI, we should provide this equivalent feature. As for Timer support, I think it can be supplied by other specs.

[alewis001]

Startup is certainly a gap I have run into so would vote for that being addressed in some way. Or, said differently, a scope that enables an object to operate as a "task" and a way to have that task start as soon as the application is initialised, i.e. it's lifecycle of not triggered by or bound to an HTTP request.

[tandraschko]

startup is easy: @Observes @Initialized(ApplicationScoped.class)

[alewis001]

Hi @tandraschko, thank you for that, I didn't know about that approach. Is that an official way of achieving at-startup or it just so happens to work? I'd worry about the points of lifecycle of watching the annotation class and it changing if this is not the spec defined way of achieving at-startup.

I may be worrying needlessly :)

[tandraschko]

Its an official way and available since 1.2

[alewis001]

Awesome! And thank you again!

[aguibert]

For timer support, perhaps CDI could introduce some mechanism to "observe" an interval of time?

I propose we define a new annotation@Schedule inspired by @javax.ejb.Schedule that would have many of the same attributes except for persistent (persistent timers is out of scope for CDI)

For example:

@ApplicationScoped
public class TimerBean {
 
    public void timerTask(@Observes @Schedule(minute = "*/5") java.time.Instant calledAt) {
      // This gets called every 5 minutes
    }
}

[rmannibucau]

What about making that an extension first? It is quite trivial to impl it and IMO it does not belong to CDI which should stay the core IoC.

EE concurrency sounds like an option but truely speaking, if not distributable it is just a matter of creating a scheduledexecutorservice in a cdi bean so guess it should stay distributable to have more added value than just proposing another api than java se one.

So high level, CDI shouldnt aim at replacing EJB because:

1. Scope is different ("put it all" for EJB vs "IoC" for CDI with a few historical exceptions/mistakes)
2. EJB already reversed part of its responsabilities (jta, scopes, singleton+startup, ...)
3. CDI was built with extension api to avoid to redo EJB like specs

So IMHO this issue must be closed and tackled at jakarta ee level (where to dispatch scheduling now since only other missing feature is bean pooling and this is no more needed these days or trivially replaced by a Semaphore when uszd as a throttler).

Just my 2 cents.

[ederks85]

Its an official way and available since 1.2

Yes, but I think this approach can be polished a bit =)

[manovotn]

Is that an official way of achieving at-startup or it just so happens to work?

Yes, that's official. If you add such an obsever into a bean, an instance of bean will have to be created eagerly to be able to invoke that observer. That works fine for singleton and application scoped bean, other scoped might have issues as the context doesn't need to be active, or in case of dependent bean, a new instance will be created, observer invoked and the instance will then be destroyed again.

[aguibert]

@ederks85 Quarkus has defined its own StartupEvent which can be observed like this:

import io.quarkus.runtime.StartupEvent;

@ApplicationScoped
class CoolService {
  void startup(@Observes StartupEvent event) { 
  }
}

Perhaps we could standardize this event? I like this approach more than the current @Observes @Initialized(ApplicationScoped.class) approach

[manovotn]

@aguibert the reason Quarkus has this is because ApplicationScoped in JVM mode is started before you get to runtime (in STATIC_INIT). This causes differences in behaviour when running in JVM versus native which may or may not affect what you sim to do with the observer. StartupEvent was introduced to fix that as it is always performed in RUNTIME_INIT phase which is consistent for both modes. See https://quarkus.io/guides/lifecycle#what-is-the-difference-from-initializedapplicationscoped-class-and-destroyedapplicationscoped-class

In other words, from purely CDI perspective @Observes @Initialized(ApplicationScoped.class) and @Observes StartupEvent would be duplicates.

[mkouba]

There is one more difference: @Observes @Initialized(ApplicationScoped.class) is not saying anything about the application itself. It's fired when the application context is initialized. Whereas @Observes StartupEvent and @io.quarkus.runtime.Startup (since Quarkus 1.3) is fired/triggered when the application is started, i.e. it may depend on some other services that are required to run before an application is considered started.

[rmannibucau]

Before adding anything we should ensure we don't duplicate something already there and fully specified.
There is another built-in way to initialize at startup some code since v1.0: through extensions and AfterValidationDeployment event.
Any reason to not enable AfterValidationDeployment event to be observed by any bean instead of limiting it to just extensions?
Concretely the spec would be something like that:

"[existing definition]. AfterValidationDeployment can also be observe by CDI beans, the container is responsible to ensure it is fired through all extensions first, and if there is no exception it is fired to all other beans."

[mkouba]

-1. I think that this would be even more confusing for users. AfterDeploymentValidation is a container lifecycle event that should only be observed by extensions (per the current wording).

[manovotn]

The line between what events are container lifecycle ones and which are standard ones is (IMO) pretty well defined, I would try and avoid blurring it, so also -1.

Besides, you are saying that you don't want to duplicate what's already there, and @Observes @Initialized(ApplicationScoped.class) is already there and is not really different from what you are suggesting here, it's just another payload.