Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WFCORE-204 CLU GUI upload for op params with ModelType.BYTES #271

Merged
merged 2 commits into from Oct 30, 2014

Conversation

ssilvert
Copy link
Contributor

No description provided.

@wildfly-ci
Copy link

Linux Build 636 is now running using a merge of cb509d0

@wildfly-ci
Copy link

Windows Build 359 is now running using a merge of cb509d0

@wildfly-ci
Copy link

Windows Build 359 outcome was SUCCESS using a merge of cb509d0
Summary: Tests passed: 2688, ignored: 56 Build time: 0:14:44

@wildfly-ci
Copy link

Linux Build 636 outcome was SUCCESS using a merge of cb509d0
Summary: Tests passed: 2688, ignored: 56 Build time: 0:17:17

ModelNode response = execute(opDesc, false);
ModelNode requestProps = response.get("result", "request-properties");
for (Property prop : requestProps.asPropertyList()) {
if (ModelType.valueOf(prop.getValue().get("type").asString()) == ModelType.BYTES) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will throw an IAE if the server-side author screwed up and there is no "type" declaration. That shouldn't happen with folks using "modern" subsystem authoring, but it's possible with some old stuff someone outside WildfFly may have.

You can do an isDefined check, or, since the ModelType of "type" is by spec supposed to be ModelType, you can do this:

ModelNode typeDesc = prop.getValue().get("type");
if (typeDesc.getType() == ModelType.TYPE && typeDesc.asType() == ModelType.BYTES) {

That will avoid failing on any bogus strings (e.g. "long") people may have stuck into a "type" description. Again, anything in WildFly/EAP itself shouldn't have such bogus stuff, so this is just being careful about external stuff.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Brian. I made your suggested change. Works well.

@bstansberry
Copy link
Contributor

@aloubyansky please approve.

@aloubyansky
Copy link
Contributor

Looks good to me.

@wildfly-ci
Copy link

Linux Build 641 is now running using a merge of 3df34f1

@wildfly-ci
Copy link

Windows Build 364 is now running using a merge of 3df34f1

@wildfly-ci
Copy link

Windows Build 364 outcome was SUCCESS using a merge of 3df34f1
Summary: Tests passed: 2688, ignored: 56 Build time: 0:14:01

@wildfly-ci
Copy link

Linux Build 641 outcome was SUCCESS using a merge of 3df34f1
Summary: Tests passed: 2688, ignored: 56 Build time: 0:17:00

@bstansberry bstansberry added the ready-for-merge This PR is ready to be merged and fulfills all requirements label Oct 29, 2014
bstansberry added a commit that referenced this pull request Oct 30, 2014
WFCORE-204 CLU GUI upload for op params with ModelType.BYTES
@bstansberry bstansberry merged commit affc9e9 into wildfly:master Oct 30, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-for-merge This PR is ready to be merged and fulfills all requirements
Projects
None yet
4 participants