2:19 p.m.
If you're writing code that manipulates potentially large chunks of the
management model, be cautious of the following:
1) org.jboss.as.controller.Registry.Tools.readModel(final Resource resource)
This makes a deep clone of all the DMR model nodes in the given resource
tree. That may be a good thing, but is expensive with large trees, so be
aware.
2) org.jboss.dmr.ModelNode.asPropertyList()
For each Property in the returned list, the 'value' member is a deep
clone of the corresponding element in the original model node. So, again
expensive with large trees, so be aware.
You can replace this:
for (Property prop : node.asPropertyList() {
String name = prop.getName();
ModelNode value = prop.getValue();
... do something with name and value
}
with
for (String name : node.keys()) {
ModelNode value = node.get(name);
... do something with name and value
}
I'll fix a few high impact cases of this usage.
Please resist the urge to send in lots of refactoring PRs until WF 10 is
done. ;)
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
5:53 p.m.
On 8/26/15 2:19 PM, Brian Stansberry wrote:
If you're writing code that manipulates potentially large chunks
of the
management model, be cautious of the following:
1) org.jboss.as.controller.Registry.Tools.readModel(final Resource resource)
This makes a deep clone of all the DMR model nodes in the given resource
tree. That may be a good thing, but is expensive with large trees, so be
aware.
2) org.jboss.dmr.ModelNode.asPropertyList()
For each Property in the returned list, the 'value' member is a deep
clone of the corresponding element in the original model node. So, again
expensive with large trees, so be aware.
You can replace this:
for (Property prop : node.asPropertyList() {
String name = prop.getName();
ModelNode value = prop.getValue();
... do something with name and value
}
with
for (String name : node.keys()) {
ModelNode value = node.get(name);
... do something with name and value
}
Note: this is not the right thing to do if node.getType() ==
ModelType.LIST with each list element a ModelType.PROPERTY. The keys()
and get(String) methods are not supported for nodes of that type.
These are unusual in the WildFly model though, other than the "address"
node of an operation object. And that node is usually is handled by
kernel code anyway.
I'll fix a few high impact cases of this usage.
Please resist the urge to send in lots of refactoring PRs until WF 10 is
done. ;)
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
6:06 a.m.
On 26/08/15 20:19, Brian Stansberry wrote:
If you're writing code that manipulates potentially large chunks
of the
management model, be cautious of the following:
1) org.jboss.as.controller.Registry.Tools.readModel(final Resource resource)
This makes a deep clone of all the DMR model nodes in the given resource
tree. That may be a good thing, but is expensive with large trees, so be
aware.
2) org.jboss.dmr.ModelNode.asPropertyList()
For each Property in the returned list, the 'value' member is a deep
clone of the corresponding element in the original model node. So, again
expensive with large trees, so be aware.
You can replace this:
for (Property prop : node.asPropertyList() {
String name = prop.getName();
ModelNode value = prop.getValue();
... do something with name and value
}
with
for (String name : node.keys()) {
ModelNode value = node.get(name);
For this line would it be better to use 'require'? It should not be
possible for it to be undefined but require would check that.
... do something with name and value
}
I'll fix a few high impact cases of this usage.
Please resist the urge to send in lots of refactoring PRs until WF 10 is
done. ;)
8:08 a.m.
On 9/3/15 6:06 AM, Darran Lofthouse wrote:
On 26/08/15 20:19, Brian Stansberry wrote:
> You can replace this:
>
> for (Property prop : node.asPropertyList() {
> String name = prop.getName();
> ModelNode value = prop.getValue();
> ... do something with name and value
> }
>
> with
>
> for (String name : node.keys()) {
> ModelNode value = node.get(name);
For this line would it be better to use 'require'? It should not be
possible for it to be undefined but require would check that.
There's no requirement that 'value' not be ModelType.UNDEFINED, and the
'require' method doesn't introduce one either. So calling 'require'
would just be a confirmation that 'keys()' isn't broken.
ModelNode.asPropertyList() also (correctly) doesn't include any checks
that the values in the properties are defined.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
3397
days inactive
3405
days old
3 comments
2 participants
participants (2)
-
Brian Stansberry -
Darran Lofthouse