rest
rest copied to clipboard
jakartaee
CDI details : Configuration
In the environment of shared CDI, if multiple Applications are started/deployed, what is the expected behavior? Do the applications share their configuration? Or do the implementations need to find a way to distinguish between the configuration, providers, and properties for each Application when injecting them? Or is the expectation to have just one microservice runtime for each application?
Was this already discussed and I missed the discussion?
@jansupol Is this related to the proposal to evaluate multiple applications in 4.0? Is that what you mean by "shared CDI"?
@spericas No, my original concern was an application server such as Glassfish running a single CDI instance while deploying multiple applications/wars and registering the respective Configuration beans into this shared CDI BeanManager.
In the end, yes, it is the same as supporting multiple Applications at a time.
@jansupol In an app server environment, shouldn't applications be completely isolated to each other? Isn't this typically accomplished using independent CLs? Maybe I'm just not understanding the "shared CDI" use case and you can elaborate it a bit more.
@spericas Is it isolated in the EAR, too? There are multiple WARs and multiple applications at the same war, too.
From what I understand, there was no decision made on whether more than one application could be defined per WAR, https://github.com/jakartaee/rest/issues/1158. In the API section there seems to be an open question of:
Review support for Application subclasses: zero or more? zero or one?
The current spec itself doesn't indicate whether multiple applications are supported.
Is it isolated in the EAR, too? There are multiple WARs and multiple applications at the same war, too.
Actually, CDI has never really worked well with an EAR. The specification just wasn't designed for it, even though it tries some things with hierarchical bean archives. EARs are more associated with EJB and JNDI, maybe just about SOAP, and many "reffing" (role-refs, datasource-refs, etc).
Modern REST / CDI applications don't seem to be used with EARs at all, at least that's my perception (and those specs somewhat back that up).
Some good resources on this:
- https://struberg.wordpress.com/2015/02/18/cdi-in-ears/
- https://balusc.omnifaces.org/2013/10/cdi-behaved-unexpectedly-in-ear-so.html
