[jboss-as7-dev] [Detyped API Description] Example of multiple values for "allowed"?

Brian Stansberry brian.stansberry at redhat.com
Thu Sep 22 10:23:42 EDT 2011


On 9/21/11 11:40 AM, Jaikiran Pai wrote:
> On Wednesday 21 September 2011 09:13 PM, Brian Stansberry wrote:
>> It's part of what I'm doing.
>>
>> I believe changes to these pool configs can't be applied directly to the
>> runtime though, at least not without a header associated with the
>> request indicating its ok to bounce the PoolConfigService. I presume
>> bouncing that service will in turn bounce any EJB services that use that
>> config. (If not, let me know, as it probably means we could just bounce
>> it by default.)
> The EJB component, upon construction, uses the PoolConfigService to
> create a runtime representation of the pool. Once that runtime
> representation is created, the EJB component no longer depends on the
> PoolConfigService. For example, if there's a PoolConfig with max pool
> size 20 and we use that for a SLSB, then we create a runtime pool
> representation with a upper bound of 20. Any subsequent changes to that
> PoolConfig (like changing the max pool size to 10) doesn't (and probably
> shouldn't) affect the already functional EJB component.
>
> Any new EJB components created/deployed using the PoolConfig should
> ofcourse use the new updated values of the PoolConfig while creating a
> runtime representation of the pool.
>
> So I think, bouncing the PoolConfigService on write attribute operations
> should be fine.
>

StatelessSessionComponentCreateService depends on PoolConfigService 
(non-optionally in some cases), and in turn the relevant 
ComponentStartService depends on it. So AIUI bouncing the PoolConfig 
service will bounce those and result in a new component being created 
and started. And the effect will cascade if any other services depend on 
StatelessSessionComponentCreateService or ComponentStartService.

>>
>> The StrictMaxPoolConfig stored in the PoolConfigService could be made
>> mutable, in which case any EJB deployments deployed in the future would
>> get the new config values, but any existing pools would remain as is.
>> That seems like an unintuitive semantic for this particular use case though.
>>

Sounds like mutating the existing service is closer to the behavior you 
describe above.

>> On 9/21/11 9:01 AM, Jaikiran Pai wrote:
>>> That looks like a separate issue. The bean instance pool attributes have
>>> currently been modelled as read-only. More of an oversight rather than
>>> intentional.
>>>
>>> I think Brian is already working on
>>> https://issues.jboss.org/browse/AS7-913 so this could be included as
>>> part of that work. Else I'll take this up separately.
>>>
>>>
>>> -Jaikiran
>>> On Wednesday 21 September 2011 06:59 PM, Andrig Miller wrote:
>>>> Why is it read-only?  Seems like you should be able to set to a
>>>> different value too.  Another bug?
>>>>
>>>> Andy
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>        *From: *"Jaikiran Pai"<jpai at redhat.com>
>>>>        *To: *jboss-as7-dev at lists.jboss.org
>>>>        *Sent: *Wednesday, September 21, 2011 4:39:34 AM
>>>>        *Subject: *Re: [jboss-as7-dev] [Detyped API Description] Example
>>>>        of multiple values for "allowed"?
>>>>
>>>>        It's a bug. It should actually look like:
>>>>
>>>>        "timeout-unit" =>    {
>>>>                             "description" =>    "The instance acquisition
>>>>        timeout
>>>>        unit",
>>>>                             "type" =>    STRING,
>>>>                             "required" =>    false,
>>>>                             "default" =>    "MINUTES",
>>>>                             "allowed" =>    [
>>>>                                 "HOURS",
>>>>                                 "MINUTES",
>>>>                                 "SECONDS",
>>>>                                 "MILLISECONDS"
>>>>                             ],
>>>>                             "access-type" =>    "read-only",
>>>>                             "storage" =>    "configuration"
>>>>                         }
>>>>
>>>>
>>>>        I'll send a pull request with the fix.
>>>>
>>>>        -Jaikiran
>>>>        On Wednesday 21 September 2011 04:02 PM, Jaikiran Pai wrote:
>>>>        >    The model for EJB3 does allow more than one timeout unit type
>>>>        (SECONDS,
>>>>        >    MINUTES and MILLISECONDS etc...). So that output doesn't look
>>>>        right. Let
>>>>        >    me take a look why.
>>>>        >
>>>>        >    -Jaikiran
>>>>        >    On Wednesday 21 September 2011 03:53 PM, David Bosschaert wrote:
>>>>        >>    Hi all,
>>>>        >>
>>>>        >>    I'm looking at the EJB3 pools timeout-unit description, which
>>>>        is the
>>>>        >>    following:
>>>>        >>    "timeout-unit" =>      {
>>>>        >>         "description" =>      "The instance acquisition timeout unit",
>>>>        >>         "type" =>      STRING,
>>>>        >>         "required" =>      false,
>>>>        >>         "default" =>      "MINUTES",
>>>>        >>         "allowed" =>      "MILLISECONDS",
>>>>        >>         "access-type" =>      "read-only",
>>>>        >>         "storage" =>      "configuration"
>>>>        >>    }
>>>>        >>
>>>>        >>    Is there an example of an attribute somewhere where 'allowed'
>>>>        has more
>>>>        >>    than 1 value? I'd like to test a console gui piece against it.
>>>>        >>
>>>>        >>    Thanks,
>>>>        >>
>>>>        >>    David
>>>>        >>    _______________________________________________
>>>>        >>    jboss-as7-dev mailing list
>>>>        >>    jboss-as7-dev at lists.jboss.org
>>>>        >>    https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>        >
>>>>        >    _______________________________________________
>>>>        >    jboss-as7-dev mailing list
>>>>        >    jboss-as7-dev at lists.jboss.org
>>>>        >    https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>>>        _______________________________________________
>>>>        jboss-as7-dev mailing list
>>>>        jboss-as7-dev at lists.jboss.org
>>>>        https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat


More information about the jboss-as7-dev mailing list