Re: [jboss-as7-dev] [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)
11:26 a.m.
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
1:39 a.m.
New subject: [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)
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.
2:10 a.m.
New subject: [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)
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
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
2:33 a.m.
New subject: [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)
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
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
2:53 a.m.
New subject: [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)
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
12:06 p.m.
New subject: [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)
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
4834
days inactive
4835
days old
5 comments
3 participants
participants (3)
-
Brian Stansberry -
Carlo de Wolf -
Heiko Braun