Bug 1195161

If you use an expression, you have to convert the doc to a non-expression value before validating. I have no intent to change this.

What is the validation scenario where this error is occurring? I am assuming it's in testing or something like that and not at runtime or this would be a different problem. As for the ports/variables in the XSD, Brian is right, we are going to need to do some form of conversion. I mean, we could setup some form of XSL transformation or do an Ant replacement before validation. Might be something we should discuss; although, it's a lot of work for a few simple variables.

Validation scenario where this error is occurring: validate xml files (mentioned in description of this bugzilla) without running EAP

Right, I get how the validation is failing, but can you point me to the tools/process you are using to do this? I would like to use yours without having to write my own. Plus, I think we should be using the same process, at least for stuff like this. Thanks.

I prepared manually xsd schema (with all necessary schemas included). Then I used xmllint:

mv all.xsd $EAP_HOME
cd $EAP_HOME
for line in `find standalone/ domain/ bin/ docs/ appclient/ | grep "\.xml$"` ; do echo $line ; xmllint --noout -schema all.xsd $line ; echo ; done

Created attachment 1030333 [details]
Xsd schema (with all necessary schemas included)

What we probably need if we are going to validate this properly is a custom type where we capture both the property name, and a port [offset]. This will allow the files to be validated correctly. However, I'm not sure how big of a change this is and all the files it would effect. Looking at that next.

Btw, cool little way to do the validation with xmllint. Thanks!

You are welcome!

Ok, there are basically two choices for a resolution of this issue,neither of them is great: 

1) create a new datatype corresponding to the system property:port mapping. To be clear, there is no native XML type that could accommodate this construct. Should we create one there are the obvious questions:
   a) where does it live in our schema
   b) where can it/should it be used
   
It looks simple at face value in that it's just a restriction of two simple types xs:string and xs:int. The construct is not the hard part,its how many areas the change would touch which are quite a few. Note, this a model change as well and as such, has a separate process for change acceptable as part of the SET workflow.

2)Create an XSLT stylesheet that transforms the value somehow. Note, it probably could not be done in a stylesheet alone as the system properties would need to be known for that particular instance to which the XML belongs. This would be the least intrusive of the two options. I'm not sure the exact amount of work but the mapping is simply

  string:port->int

Either approach has it's drawbacks and I really just need to know if this is something we want to invest time. This only comes into effect, to my knowledge, when we are running in domain mode using port offsets to generate nth member of the cluster/domain. 

The major drawback in not doing this is that when the above configuration is used we have no effective way to validate the files. Important yes, model changing worth...I'm not so sure.

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Radovan Netuka <rnetuka> updated the status of jira JBEAP-4263 to Closed

Rejected on upstream
https://github.com/wildfly/wildfly-core/pull/1506

Radovan Netuka <rnetuka> updated the status of jira JBEAP-4263 to Reopened

Radovan Netuka <rnetuka> updated the status of jira JBEAP-4263 to Resolved