Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 3.1.1_b12
    • Fix Version/s: future release
    • Component/s: cdi
    • Labels:
      None
    • Environment:

      GF3.1.1 Win7 Pro SP1 (64 Bit) JDK 1.6.0_26

      Description

      Sometimes there is a need to modify properties at runtime, i. e. modifying business level application behaviour changes without restarting the domain. This makes sense for example in public services where a planned outage is not wanted.

      This can be done in GF3.1.1 by using custom properties which are looked up using JNDI code.

      But JNDI is not as smart as CDI, so one wishes to get injection instead. While the injection works, it is static. This means, the change will not get reflected until a domain restart.

      We would be really glad if this would work dynamically, i. e. a modification of a custom property would inject at once without the need to restart the domain or the need to use JNDI code.

        Activity

        Hide
        Cheng Fang added a comment -

        Transfer to cdi for evaluation.

        Show
        Cheng Fang added a comment - Transfer to cdi for evaluation.
        Hide
        mkarg added a comment -

        This might be true for completely selfdeveloped custom types, but it could be implemented into that types that GlassFish ships with already. That means, the fact that CDI forces one-time injection does not prevent the GlassFish-custom-types from working dynamically inside themselves.

        Show
        mkarg added a comment - This might be true for completely selfdeveloped custom types, but it could be implemented into that types that GlassFish ships with already. That means, the fact that CDI forces one-time injection does not prevent the GlassFish-custom-types from working dynamically inside themselves.
        Hide
        jjsnyder83 added a comment - - edited

        Could you provide an example of what you want?

        Show
        jjsnyder83 added a comment - - edited Could you provide an example of what you want?
        Hide
        mkarg added a comment -

        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".

        Example:

        @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.

        Show
        mkarg added a comment - 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". Example: @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.
        Hide
        jjsnyder83 added a comment -

        I think what you're looking for is a portable extension that defines beans for properties. The bean implementations either use jndi, jmx, or something else to lookup the value of the property each time it's accessed. Please check DeltaSpike to see if someone has already written an extension to do this.

        CDI requires a scope for objects that it manages so that it knows when to create a new instance under the covers (anything but @Dependent is proxied so that when the injected proxy is access CDI can get the correct instance based on the scope of the injected object.)

        Show
        jjsnyder83 added a comment - I think what you're looking for is a portable extension that defines beans for properties. The bean implementations either use jndi, jmx, or something else to lookup the value of the property each time it's accessed. Please check DeltaSpike to see if someone has already written an extension to do this. CDI requires a scope for objects that it manages so that it knows when to create a new instance under the covers (anything but @Dependent is proxied so that when the injected proxy is access CDI can get the correct instance based on the scope of the injected object.)

          People

          • Assignee:
            phil.zampino
            Reporter:
            mkarg
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: