Here is an example scenario:
An EAR-packaged application might need to have a switch that enables or disabled one particular business process (like a boolean for "this feature is enabled"). For example, the process could be that data is to be synchronized between the application and an external data source or sink (like another external application). If the EAR-customer also runs that external application, he switches this sync feature on (if he likes). Otherwise, he switches this feature off (= the default).
Possibly, the EAR-packaged application is used 24x7, and he wants to switch on the sync feature, there is no time to shutdown the container to trigger a CDI-reinjection of the boolean. But to simplify coding, the EAR-vendor does not like to use JNDI (which would be "live"). So my proposal to get "live" values in CDI would be that GlassFish for this reason comes with an implementation of custom properties that are injectable, but that will update "live" under the hood.
Here is how GlassFish could do that:
A solution could be that the static instance (here: boolean value) that is getting CDI-injected is a dynamic wrapper around JNDI but not just a Java primitive. This means, PrimitivesAndStringFactory will in fact not provide a copy of primitive value (boolean), but a reference (hence, java.lang.Boolean), where the reference is always the same but simply either points to the customized value or uses DynamicProxy API, ASM API, or whatever tweak to get a dynamic resolution of the value (e. g. using JNDI internally). That reference is statically injected, but as it is not a copy but a "living" object, it will dynamically reflect any value changes "live".
@Inject Boolean myValue; // GlassFish injects an object that looks like a Boolean but actually will use JNDI to always return the latest "live" value when any of java.lang.Boolean's methods are invokes.
A different solution could be that CDI injects at the moment the EJB component is getting from the pool instead of when being constructed. That way, a GlassFish factory could simply lookup the value each time the factory is triggered, hence, every time the EJB is taken out of the pool.