"scott.stark(a)jboss.org" wrote : I think these are warnings coming from updates
post template creation of the destination. They can't be read-only as in ignored
because the template uses the same properties.
|
I think its fine for the ObjectName, JNDIName, Clustered properties to be read-only in the
console since we support being able to set read-only properties once at creation time and
then not edit them later.
"scott.stark(a)jboss.org" wrote : We don't know if the component has failed to
apply the change without an exception being thrown here. This does not seem to be the case
as the change is ignored and the log message the only indication of failure.
|
From trying to make changes to properties such as DownCacheSize via
the jmx-console its clear, as you say, that any updates that are attempted are ignored by
the underlying messaging implementation, i.e. the old value remains after the update.
Given that, would it not be possible for the profile service to try to make a change on a
property, then requery that property to see if that change had "stuck"? If not
an exception would be raised. This seems like a bit of hack to support this one particular
case, (where really the managed resource itself should be throwing the exception) but I
dont think its practical to expect the JBM team to change how this is implemented at this
stage.
"scott.stark(a)jboss.org" wrote : If the properties are updated to be *_RESTART,
then we can avoid dispatching the change to the runtime component at the profileservice
level and avoid the warning it emits.
|
If this is achievable quickly then it sounds like a reasonable use for the activation
policies, since we're not really going to be able to use them elsewhere yet.
Thanks
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222821#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...