Re: [jboss-as] Fix the default-stateful-access-timeout and default-singleton-access-timeout to be more consistent with the management model, by making them attributes (0b149ef)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [jboss-as] Fix the default-stateful-access-timeout and default-singleton-access-timeout to be more consistent with the management model, by making them attributes (0b149ef)

Brian Stansberry
This was in response to a question about a patch that changed expression
support for an attribute. Replying to the full jboss-as7-dev list as an
FYI to others:

On 10/11/11 10:56 AM, Jaikiran wrote:
> No specific reason against it. I wasn't sure what the convention was. Are we allowing expressions for most of the attribute values and only disallowing wherever it makes sense?
>

This has evolved a bit, so yours is a good question. The console guys
are actively pursuing supporting expressions, so that has removed a
barrier we had to being aggressive about allowing them.  The fairly
recent AttributeDefinition stuff that the ejb3 subsystem and some others
is using also greatly reduces the chances of screwing them up, so we can
be more aggressive.

At this point we should support them anywhere it doesn't give you a
queasy feeling. ;) If you can think of an argument not to support them
someplace; fine don't. If you just have a sixth sense it's a bad idea;
fine, don't support an expression. We can always add support in a later
release, but we can't remove it.  But otherwise, go ahead and support
it. Expressions will be very important in cloud use cases where
customizing the config file on a per-server basis is a poor option.

--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jboss-as] Fix the default-stateful-access-timeout and default-singleton-access-timeout to be more consistent with the management model, by making them attributes (0b149ef)

Heiko Braun


The question you should ask yourself is which parts should be configured externally?
I.e. a typical scenario for expressions are configuration values that change depending on the environment (staging/production).

I would suggest to be _very_ conservative about allowing expressions in your model.
It's definitely wrong to allow them anywhere, just because you are not sure if they make sense.
As Brian said: We can add them anytime, but removing them is not an option.

Some further clarification what "adding expressions" actually means:

a) attribute meta data "expressions-allowed"
b) expressions values that we provide out of the box

a) is a requirement for b). But you are not forced to provide b).

My advice: Support expressions when it makes real sense. But back your decision with some a use case.

Expressions are a powerful way to extend our default configuration means.
At the same time they lead to ambiguity and all kinds of error scenarios. So use them sparely.


My 2 cents.


Ike

On Oct 11, 2011, at 6:26 PM, Brian Stansberry wrote:

>  But otherwise, go ahead and support
> it. Expressions will be very important in cloud use cases where
> customizing the config file on a per-server basis is a poor option.


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jboss-as] Fix the default-stateful-access-timeout and default-singleton-access-timeout to be more consistent with the management model, by making them attributes (0b149ef)

Heiko Braun


Maybe this has been discussed elsewhere, but looking at the EJB description I can see that expressions are allowed basically anywhere.
This is an example how is should _not_ be done. I.e. the "default-mdb-instance-pool" is certainly not something you would like to configure by external means, do you?

Ike

On Oct 12, 2011, at 8:39 AM, Heiko Braun wrote:

>
>
> The question you should ask yourself is which parts should be configured externally?
> I.e. a typical scenario for expressions are configuration values that change depending on the environment (staging/production).
>
> I would suggest to be _very_ conservative about allowing expressions in your model.
> It's definitely wrong to allow them anywhere, just because you are not sure if they make sense.
> As Brian said: We can add them anytime, but removing them is not an option.
>
> Some further clarification what "adding expressions" actually means:
>
> a) attribute meta data "expressions-allowed"
> b) expressions values that we provide out of the box
>
> a) is a requirement for b). But you are not forced to provide b).
>
> My advice: Support expressions when it makes real sense. But back your decision with some a use case.
>
> Expressions are a powerful way to extend our default configuration means.
> At the same time they lead to ambiguity and all kinds of error scenarios. So use them sparely.
>
>
> My 2 cents.
>
>
> Ike
>
> On Oct 11, 2011, at 6:26 PM, Brian Stansberry wrote:
>
>> But otherwise, go ahead and support
>> it. Expressions will be very important in cloud use cases where
>> customizing the config file on a per-server basis is a poor option.
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jboss-as] Fix the default-stateful-access-timeout and default-singleton-access-timeout to be more consistent with the management model, by making them attributes (0b149ef)

Carlo de Wolf
So far I've only seen subjective considerations, which makes any
solution a valid one.
What are the objective considerations?

On 10/12/2011 09:10 AM, Heiko Braun wrote:
>
> Maybe this has been discussed elsewhere, but looking at the EJB description I can see that expressions are allowed basically anywhere.
> This is an example how is should _not_ be done. I.e. the "default-mdb-instance-pool" is certainly not something you would like to configure by external means, do you?

I can easily counter this with: why not?

Seriously I'm thinking of something like configuration items that are
based on the system environment.
This would have the bind.address make sense.

A sliding one would be the default RA.

It would make default-mdb-instance-pool a no-go, because that's an AS
configuration item without any dependencies on system environment.

Carlo

> Ike
>
> On Oct 12, 2011, at 8:39 AM, Heiko Braun wrote:
>
>>
>> The question you should ask yourself is which parts should be configured externally?
>> I.e. a typical scenario for expressions are configuration values that change depending on the environment (staging/production).
>>
>> I would suggest to be _very_ conservative about allowing expressions in your model.
>> It's definitely wrong to allow them anywhere, just because you are not sure if they make sense.
>> As Brian said: We can add them anytime, but removing them is not an option.
>>
>> Some further clarification what "adding expressions" actually means:
>>
>> a) attribute meta data "expressions-allowed"
>> b) expressions values that we provide out of the box
>>
>> a) is a requirement for b). But you are not forced to provide b).
>>
>> My advice: Support expressions when it makes real sense. But back your decision with some a use case.
>>
>> Expressions are a powerful way to extend our default configuration means.
>> At the same time they lead to ambiguity and all kinds of error scenarios. So use them sparely.
>>
>>
>> My 2 cents.
>>
>>
>> Ike
>>
>> On Oct 11, 2011, at 6:26 PM, Brian Stansberry wrote:
>>
>>> But otherwise, go ahead and support
>>> it. Expressions will be very important in cloud use cases where
>>> customizing the config file on a per-server basis is a poor option.
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jboss-as] Fix the default-stateful-access-timeout and default-singleton-access-timeout to be more consistent with the management model, by making them attributes (0b149ef)

Heiko Braun

On Oct 12, 2011, at 9:33 AM, Carlo de Wolf wrote:

On 10/12/2011 09:10 AM, Heiko Braun wrote:

Maybe this has been discussed elsewhere, but looking at the EJB description I can see that expressions are allowed basically anywhere.
This is an example how is should _not_ be done. I.e. the "default-mdb-instance-pool" is certainly not something you would like to configure by external means, do you?

I can easily counter this with: why not?

Seriously I'm thinking of something like configuration items that are based on the system environment.
This would have the bind.address make sense.

A sliding one would be the default RA.

It would make default-mdb-instance-pool a no-go, because that's an AS configuration item without any dependencies on system environment.


You seem to have answered the question yourself. Expressions are useful when you need to configure certain aspects by external means or depending on the environment. 


Ike


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jboss-as] Fix the default-stateful-access-timeout and default-singleton-access-timeout to be more consistent with the management model, by making them attributes (0b149ef)

Brian Stansberry
On 10/12/11 2:53 AM, Heiko Braun wrote:

>
> On Oct 12, 2011, at 9:33 AM, Carlo de Wolf wrote:
>
>> On 10/12/2011 09:10 AM, Heiko Braun wrote:
>>>
>>> Maybe this has been discussed elsewhere, but looking at the EJB
>>> description I can see that expressions are allowed basically anywhere.
>>> This is an example how is should _not_ be done. I.e. the
>>> "default-mdb-instance-pool" is certainly not something you would like
>>> to configure by external means, do you?
>>
>> I can easily counter this with: why not?
>>
>> Seriously I'm thinking of something like configuration items that are
>> based on the system environment.
>> This would have the bind.address make sense.
>>
>> A sliding one would be the default RA.
>>
>> It would make default-mdb-instance-pool a no-go, because that's an AS
>> configuration item without any dependencies on system environment.
>
>
> You seem to have answered the question yourself. Expressions are useful
> when you need to configure certain aspects by external means or
> depending on the environment.
>

It's the "need to configure certain aspects by external means" one that
can become pretty broad. Particularly in cloud cases where you may need
to build up a separate image just to have some variation in a config
file setting. That's pretty expensive.

That said, I would have no complaint about having these ejb3
"default-xxx" attributes not support expressions. They are references
from one bit of the model to another and without a solid use case that
ties back to the system environment I'm fine with not supporting
expressions for such things.


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev