[Design of Management Features on JBoss] - Re: JBAS-6672, null values and defaults
by charles.crouch＠jboss.com
"scott.stark(a)jboss.org" wrote : "charles.crouch(a)jboss.com" wrote :
| | I think this is fine, as long as we can support the following scenarios:
| |
| | a) ManagedProperty wraps an int and the user does not want to give it a value (i.e. he's happy with whatever value the server default is e.g. 0, 20, 100).
| | The user sets unset=true in the console and then the plugin calls property.setRemoved(true).
| |
| | b) ManagedProperty wraps an int and the user specifies no value.
| | The user sets unset=false in the console, but leaves the value blank. The plugin will do property.setValue(null) and PS will initialize the underlying value to 0, which is the value the console will see next time it queries the PS.
| | I see this as just the fallout from using int's in a components' managed api, if the component developer wants to support letting the user specify null, then they should use an Integer.
| |
|
| Agreed. So the only issue is whether we make the default value part of the management api on the ManagedProperty so that its both documented what the defaults are, and there is consistent behavior between a primitive with an initializer (int x = 1) and @ManagmentProperty(defaultValue="1"). I don't see I'll have that working by tomorrow, so we'll have to talk about if this is worthwhile pursuing for CR1 vs other issues tomorrow.
|
So it looks like we really dont even have to worry about b) because the config validation in the console will prevent this situation from happening, i.e. we wont let the user specify a null value for ints or Integers.
So overall the most important thing is to have property.setRemoved() cause nothing to be persisted for the managed property, and that a default (if specified somewhere) is applied to the actual running instance. [This could just be letting the component itself choose the default, I don't think it has to come from the ManagedProperty annotation for CR1, though it would make sense in the future.] This is what I see as the core issue that needs resolving for CR1.
If we don't have this function for managedproperty's which are primitives then that's not great, but I don't necessarily see it as a blocker since there probably not that many such properties.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223088#4223088
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223088
17 years
[Design of Management Features on JBoss] - Re: JBAS-6672, null values and defaults
by scott.stark＠jboss.org
"charles.crouch(a)jboss.com" wrote :
| I think this is fine, as long as we can support the following scenarios:
|
| a) ManagedProperty wraps an int and the user does not want to give it a value (i.e. he's happy with whatever value the server default is e.g. 0, 20, 100).
| The user sets unset=true in the console and then the plugin calls property.setRemoved(true).
|
| b) ManagedProperty wraps an int and the user specifies no value.
| The user sets unset=false in the console, but leaves the value blank. The plugin will do property.setValue(null) and PS will initialize the underlying value to 0, which is the value the console will see next time it queries the PS.
| I see this as just the fallout from using int's in a components' managed api, if the component developer wants to support letting the user specify null, then they should use an Integer.
|
Agreed. So the only issue is whether we make the default value part of the management api on the ManagedProperty so that its both documented what the defaults are, and there is consistent behavior between a primitive with an initializer (int x = 1) and @ManagmentProperty(defaultValue="1"). I don't see I'll have that working by tomorrow, so we'll have to talk about if this is worthwhile pursuing for CR1 vs other issues tomorrow.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223082#4223082
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223082
17 years
[Design of Management Features on JBoss] - Re: JBAS-6672, null values and defaults
by charles.crouch＠jboss.com
"scott.stark(a)jboss.org" wrote :
| The latest jboss-managed 2.1.0.CR6 simply maps MetaValues with null values onto the corresponding primitive unintialized value when the MetaValue is unwrapped, so essentially there is no way a primitive will have a null value. I view this as akin to auto promotion of nulls so that one does not have to track whether a property is a primitive.
|
I think this is fine, as long as we can support the following scenarios:
a) ManagedProperty wraps an int and the user does not want to give it a value (i.e. he's happy with whatever value the server default is e.g. 0, 20, 100).
The user sets unset=true in the console and then the plugin calls property.setRemoved(true).
b) ManagedProperty wraps an int and the user specifies no value.
The user sets unset=false in the console, but leaves the value blank. The plugin will do property.setValue(null) and PS will initialize the underlying value to 0, which is the value the console will see next time it queries the PS.
I see this as just the fallout from using int's in a components' managed api, if the component developer wants to support letting the user specify null, then they should use an Integer.
Cheers
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223076#4223076
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223076
17 years
[Design of Management Features on JBoss] - Re: JBAS-6672, null values and defaults
by ips
anonymous wrote : "ips" wrote:
|
| 1) Will:
|
| managedComponent.getProperties().remove("foo")
|
| be semantically equivalent to:
|
| managedComponent.getProperty("foo").setRemoved(true)
|
| ? (I think it should be)
|
|
| Yes it should.
Then it could be argued that the setRemoved/isRemoved API on ManagedProperty is not truly needed. The only advantages I see of including the API are that it's a bit easier to document Javadoc-wise, and it's easier to implement the isMandatory check I described in my previous post.
anonymous wrote : The latest jboss-managed 2.1.0.CR6 simply maps MetaValues with null values onto the corresponding primitive uninitialized value when the MetaValue is unwrapped, so essentially there is no way a primitive will have a null value. I view this as akin to auto promotion of nulls so that one does not have to track whether a property is a primitive.
I don't love this auto-promotion, because I think many users will still try to use simpleValue.setValue(null) to remove/unspecify that property. For non-primitive SimpleValues, this isn't a big deal, because 99% of the time it will have the same ultimate effect on the managed resource. But for primitive SimpleValues, it will end up setting the primitive to the Java init default, which will often not be the same as the underlying managed resource's default for the properties.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223074#4223074
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223074
17 years
[Design of Management Features on JBoss] - Re: JBAS-6672, null values and defaults
by scott.stark＠jboss.org
"ips" wrote :
| 1) Will:
|
| managedComponent.getProperties().remove("foo")
|
| be semantically equivalent to:
|
| managedComponent.getProperty("foo").setRemoved(true)
|
| ? (I think it should be)
|
|
Yes it should.
"ips" wrote :
| 2) Will managementView.updateComponent() throw an Exception if for a property (managedProperty.isMandatory() && managedProperty.isRemoved()) is true? I think it should, because not specifying a value for a mandatory property should be considered a client error. The other option would be having setRemoved(true) throw an Exception if the prop is mandatory.
|
I would say calling setRemoved(true) on a manadatory property is where the exception should be thrown. Right now that is not the case so an update to jboss-managed would be needed. We can have a duplicate check in the server updateComponent code to add that behavior now, and ensure the server enforces the expected behavior.
"ips" wrote :
| 3) I think primitive SimpleValues should not be allowed to have a value of null. They are primitive after all. Either updateComponent() could throw an Excpetion, or, to nip it in the bud, the impl of setValue() in SimpleValueSupport could be changed to:
|
| public void setValue(Serializable value)
| | {
| | if (value == null && this.metatype.isPrimitive())
| | throw new IllegalArgumentException("Primitive SimpleValues cannot have a value of null.");
| | this.value = value;
| | }
|
The latest jboss-managed 2.1.0.CR6 simply maps MetaValues with null values onto the corresponding primitive unintialized value when the MetaValue is unwrapped, so essentially there is no way a primitive will have a null value. I view this as akin to auto promotion of nulls so that one does not have to track whether a property is a primitive.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223071#4223071
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223071
17 years
[Design of Management Features on JBoss] - Re: JBAS-6672, null values and defaults
by ips
In the RHQ config GUI, we don't make a distinction between null values and unspecified/removed values; I think we figured that 99% of the time calling setValue(null) on n underlying managed resource would be equivalent to not calling the setter at all. That said, I can understand you wanting to make the distinction just to support all possible use cases, and the API you describe will work just fine for us. A few questions:
1) Will:
managedComponent.getProperties().remove("foo")
be semantically equivalent to:
managedComponent.getProperty("foo").setRemoved(true)
? (I think it should be)
2) Will managementView.updateComponent() throw an Exception if for a property (managedProperty.isMandatory() && managedProperty.isRemoved()) is true? I think it should, because not specifying a value for a mandatory property should be considered a client error. The other option would be having setRemoved(true) throw an Exception if the prop is mandatory.
3) I think primitive SimpleValues should not be allowed to have a value of null. They are primitive after all. Either updateComponent() could throw an Excpetion, or, to nip it in the bud, the impl of setValue() in SimpleValueSupport could be changed to:
public void setValue(Serializable value)
| {
| if (value == null && this.metatype.isPrimitive())
| throw new IllegalArgumentException("Primitive SimpleValues cannot have a value of null.");
| this.value = value;
| }
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223065#4223065
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223065
17 years
[Design of Management Features on JBoss] - Re: JBAS-6672, null values and defaults
by scott.stark＠jboss.org
"charles.crouch(a)jboss.com" wrote : "emuckenhuber" wrote : Although i still think doing managedProperty.setValue(null); should not replace it with a default value.
| |
|
| Ok, so what should we use?
|
I think we are going to have to use the ManagedProperty.setRemoved(true) to indicate that a property has no value to be applied to the underlying metadata. If we don't want to persist the default values, I don't see that a default value at the ManagedProperty level has much meaning. It would not be equivalent a missing element on an xml configuration. I suppose we could treat it like that to ensure the uninitialized values are part of the management interface, and the persistent view would have a 'managed-property default=true' setting. The main problem I see with this vs using ManagedProperty.setRemoved(true) is having to update the ManagedProperty settings to reflect the proper default values.
A ManagedProperty.setValue(null) should only be mapping to either an actual null or an uninitialized value for a primitive. I agree with Emanuel that we can't effectively duplex the meaning of a null to indicate a missing configuration value.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223055#4223055
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223055
17 years
[Design of POJO Server] - Re: Annotation for MC bean
by anil.saldhana＠jboss.com
Galder, did you add the lifecycle declaration to any of the xml configuration files?
Something like I am doing (not yet checked in):
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
|
| <!-- Support for @Password -->
| <lifecycle-configure xmlns="urn:jboss:aop-beans:1.0"
| name="PasswordRegistrationAdvice"
| class="org.jboss.security.integration.password.PasswordLifecycleCallback"
| classes="@org.jboss.security.integration.password.Password"
| manager-bean="AspectManager"
| manager-property="aspectManager">
| </lifecycle-configure>
|
| <lifecycle-create xmlns="urn:jboss:aop-beans:1.0"
| name="PasswordCreateDestroyAdvice"
| class="org.jboss.security.integration.password.PasswordLifecycleCallback"
| classes="@org.jboss.security.integration.password.Password"
| manager-bean="AspectManager"
| manager-property="aspectManager">
| </lifecycle-create>
|
| <lifecycle-install xmlns="urn:jboss:aop-beans:1.0"
| name="PasswordStartStopAdvice"
| class="org.jboss.security.integration.password.PasswordLifecycleCallback"
| classes="@org.jboss.security.integration.password.Password"
| manager-bean="AspectManager"
| manager-property="aspectManager">
| </lifecycle-install>
|
|
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223040#4223040
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223040
17 years