I almost forgot to mention, the DEBUG log shows up when I execute "ls" or ":read-resource" on that address. I've never executed ":read-attribute" against 'properties' attribute.
I was trying to build switchyard so I would see what are you guys doing but I failed at building it.
One thing that i can say for sure is that you need subsystem tests, as the test harness we provide testing subsystems tests all the scenarios you have here.
can you ping me (ctomc) on #wildfly-dev or at wildfly hipchat it will be faster to discuss this.
With thanks to Tomaz's big help, we introduced WildFly subsystem test into SwitchYard!
Still I don't yet hit the root cause of this issue though, now this code looks fishy... setting self-crafted ModelNode on a deployment submodel directly
I'll look for an alternative way working on both of EAP6 and WF10.
It looks setting ModelNode on the deployment model shouldn't be a problem. Rather than that, the ResourceDefinition for that deployment model seems to matter. On EAP6, even if the complex ModelNode is set on that deployment model without defining any attribute in ResourceDefinition, read-resource returns JSON representation of that ModelNode, but it fails on WF10 with complaining the attribute is not defined. I can't change this behavior for EAP6 (e.g. defining all attributes), so need to add different code for WF10.