Socket-bindings all of a sudden have an embedded EXPRESSION_VALUE element (and other stuff) {"outcome" : "success", "result" : {"default-interface" : "public", "local-destination-outbound-socket-binding" : null, "name" : "standard-sockets", "port-offset" : { "EXPRESSION_VALUE" : "${jboss.socket.binding.port-offset:0}" }, "remote-destination-outbound-socket-binding" : {"mail-smtp" : null}, "socket-binding" : {"https" : null, "management-http" : null, "remoting" : null, "http" : null, "txn-recovery-environment" : null, "management-https" : null, "management-native" : null, "txn-status-manager" : null, "osgi-http" : null}}}
[17:52:55] <pilhuhn> wtf "result" => expression "${jboss.socket.binding.port-offset:0}" [17:53:10] <+ctomc> pilhuhn: what is wrong with that? [17:53:26] <+ctomc> pilhuhn: that is perfectly valid expresion ;) [17:53:49] <pilhuhn> that it has changed from the past ; that the "expression " prefix looks strange and adds more complexity to clients [17:54:40] <+ctomc> pilhuhn: it is not strange, this is the proper format, but if you call toString() you get that [17:54:54] <+bstansberry> pilhuhn: that's always been the representation ModelType.EXPRESSION [17:54:57] <pilhuhn> "my call" to toString() is actually the CLI [17:55:43] <pilhuhn> I guess "always" is exaggerated, as those did not show up in the past in the socket binding groups (can't say when it started though) [17:55:53] <+ctomc> pilhuhn: if you attribute supports expresions, you should call attribute.resolveModelAttribute(..) [17:56:32] <pilhuhn> So if a user wants to use ${foo:x} I need to write-attribute(name=foo,value="expression ${foo:x}") ? [17:56:48] <+bstansberry> pilhuhn: no [17:57:07] <+bstansberry> on the server side if the attribute supports expressions, we detect the expression syntax and convert [17:57:38] <+ctomc> pilhuhn: but it is really easy if you use AttributeDefintion, othervise it is quite some work... [17:58:06] ChanServ sets mode +v mdobozy [17:58:08] <pilhuhn> ctomc how does that map to json? [17:58:44] <+ctomc> pilhuhn: not sure, but afaik it would be just ${for:x} [17:58:51] <+ctomc> pilhuhn: there is difference between toString() [17:58:57] <+ctomc> pilhuhn: and asString() [17:59:14] <+ctomc> pilhuhn: asString() will return ${for:x} [18:02:55] <pilhuhn> ctomc this is the JSON that I get back from the API: "port-offset" : { "EXPRESSION_VALUE" : "${jboss.socket.binding.port-offset:0}" }, [18:03:27] <pilhuhn> so it is not really me (= the json/http client) who is selecting toString() or asString() [18:04:36] <+ctomc> pilhuhn: hmm, let me check something... [18:06:56] <+bstansberry> pilhuhn: toString() is a formal representation, which is what the management interface will return, since it retains information [18:07:39] <pilhuhn> bstansberry I understand -- it is just that it is on the as-side ; a client can't choose to use asString() or toString() [18:08:04] <+bstansberry> pilhuhn: correct [18:08:08] <+ctomc> pilhuhn: there is acutaly special handing of marshaling to json for expresion values [18:08:52] <+ctomc> bstansberry: is is correct that asString() on ExpressionValue() returns whole expresion string? [18:08:52] <pilhuhn> If the input of ${foo:bar} is enough for the model to work, I can rip out the EXPRESSION_VALUE and we call it a day [18:09:22] <pilhuhn> ctomc the above snippet is from a live query against EAP6 DR 13 (irc) [18:09:24] <+bstansberry> pilhuhn: yes, if you post back ${foo:bar} it will work [18:09:43] <+ctomc> pilhuhn: i see it is :) [18:10:04] <pilhuhn> (meaning I did not made it up ) [18:10:37] <+ctomc> pilhuhn: no you didn't, just didn't realize that expressions have its own marshaling [18:10:55] <+ctomc> pilhuhn: best way to do it is just remove EXPRESSION_VALUE and that is it [18:11:12] <pilhuhn> I guess so. Ok, thanks
This got a lot more complicated: [12:00:35] <pil-afk> ctomc just writing back the expression does not work: Operation <CompositeOperation{steps=23}> returned <"JBAS014688: Wrong type for port. Expected [EXPRESSION, INT] but was STRING","rolled-back":true}, [12:03:47] <pilhuhn> ctomc Ha! :read-resource-description says [12:03:48] <pilhuhn> "attributes" => { [12:03:48] <pilhuhn> "port" => { [12:03:48] <pilhuhn> "type" => INT, [12:03:48] <pilhuhn> "description" => "Number of the port to which the socket should be bound.", [12:03:48] <pilhuhn> "expressions-allowed" => true, [12:03:55] <pilhuhn> so clearly an expression != INT [12:04:23] <+emuckenhuber> yeah, you need to check the "expressions-allowed" [12:04:48] <+ctomc> pilhuhn: what you dont see is how writehandler validator is set [12:04:59] <+emuckenhuber> however we don't want to loose the actual type information, only because we allow expressions [12:06:32] <pilhuhn> emuckenhuber expression is a subresource which is != INT or string. This is very ambigous [12:07:54] <pilhuhn> emuckenhuber actually it is described as "attributes" => { [12:07:54] <pilhuhn> "port" => { [12:07:54] <pilhuhn> "type" => INT, [12:08:38] <+emuckenhuber> pilhuhn: hmm, so this breaks your plugin metadata generation tool - i guess? [12:08:40] <pilhuhn> If I can send {"EXPRESSION_VALUE",xxx} for everything - even raw integers, I can use that [12:08:54] <maximilienw> ctomc: oh yes missed the second version on folder -_- [12:09:14] <+emuckenhuber> pilhuhn: well you need to also also at the "expressions-allowed" => true - information [12:09:19] <pilhuhn> emuckenhuber the tool is the smallest issue - it breaks the config mapping from RHQ to AS [12:09:30] <pilhuhn> emuckenhuber but an expression is not INT [12:09:47] <+emuckenhuber> pilhuhn: yes, but a port is an int - and we don't want to loose the type information [12:09:56] <pilhuhn> I understand [12:10:01] <+emuckenhuber> only because there is a system property [12:10:13] ChanServ sets mode +v Jaikiran [12:10:17] <+stuartdouglas> rhusar: Will you be able to test that fix? [12:10:20] <pilhuhn> Can I send {"EXPRESSION_VALUE",1234} for the non ${..} case? [12:10:54] <+emuckenhuber> if it's an INT and "expressions-allowed" => false - then this will fail [12:10:54] <+stuartdouglas> possibly, although I don't think so [12:11:05] <+emuckenhuber> if it does not it's a bug in the validation
There is also a new freaky attribute: "client-mappings" => { "type" => LIST, "description" => "Specifies zero or more client mappings for this socket binding. A client connecting to this socket should use the destination address specified in the mapping that matches its desired outbound interface. This allows for advanced network topologies that use either network address translation, or have bindings on multiple network interfaces to function. Each mapping should be evaluated in declared order, with the first successful match used to determine the destination.", "expressions-allowed" => false, "nillable" => true, "value-type" => { "source-network" => { "description" => "Source network the client connection binds on. This value is in the form of ip/netmask. A client should match this value against the desired client host network interface, and if matched the client should connect to the corresponding destination values. If omitted this mapping should match any interface.", "type" => STRING, "nillable" => true, "min-length" => 1 }, "destination-address" => { "description" => "The destination address that a client should connect to if the source-network matches. This value can either be a hostname or an ip address.", "type" => STRING, "nillable" => false, "min-length" => 1 }, "destination-port" => { "description" => "The destination port that a client should connect to if the source-network matches. If omitted this mapping will reuse the effective socket binding port.", "type" => INT, "nillable" => true, "min" => 0, "max" => 65535 } }, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "all-services" },
[12:19:16] <pilhuhn> [standalone@localhost:9999 socket-binding=http] :write-attribute(name=port,value=${jboss.management.http.port:19990}) [12:19:16] <pilhuhn> { [12:19:16] <pilhuhn> "outcome" => "failed", [12:19:16] <pilhuhn> "failure-description" => "JBAS014688: Wrong type for port. Expected [EXPRESSION, INT] but was STRING", [12:19:16] <pilhuhn> "rolled-back" => true [12:19:16] <pilhuhn> } [12:19:59] <+ctomc> pilhuhn: i see, you are trying to set expression itself [12:20:07] <+ctomc> pilhuhn: that does not work for me either [12:21:12] <+ctomc> pilhuhn: does it work if you just set a static number 19990 ? and not expression ${jboss.management.http.port:19990} [12:21:16] <pilhuhn> which is what bstans_afk told be should work -- I expect users would want to do that -- e.g. set the http port per default to 80 unless overwritten [12:21:42] <+ctomc> pilhuhn: this is exacly what it should do [12:22:01] <+ctomc> pilhuhn: but i am not sure if write-attribute commands know how to handle this [12:22:21] <pilhuhn> I'll open a JIRA on this [12:22:46] <+ctomc> pilhuhn: please do, as it looks like modelType validator kicks in and preventns any further processing [12:26:49] <+emuckenhuber> pilhuhn: so setting { "EXPRESSION_VALUE" : "${....}" } does not work? [12:27:26] <pilhuhn> emuckenhuber see above [12:27:36] <+emuckenhuber> the CLI stuff? yeah, that might be but it's different [12:28:08] <+emuckenhuber> an expression is a different type, so i'd expect it to fail if the CLI does not treat that differently - which should be fixed... [12:28:15] <pilhuhn> emuckenhuber I see the exact same if I send json {name="port",value="${…}"} -- which is what I've been told that it would work [12:29:29] <pilhuhn> Different, but related question: do those expressions only show up in socket-bindings or could they show up everywhere ? [12:29:57] <+emuckenhuber> everywhere where "expressions-allowed" => true [12:30:17] <pilhuhn> My issue is that I don't really have a way to add the extra meta-data of "this may be an int, but could be an expression "
per 3/12/2012 bz triage (loleary, crouch, foley)
master 0442c0674f53
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.