qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Godfrey (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (QPID-6009) [Java Broker] Add meta data to managed attributes to provide information where valid values are restricted
Date Sun, 17 Aug 2014 11:13:18 GMT

    [ https://issues.apache.org/jira/browse/QPID-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14099933#comment-14099933
] 

Rob Godfrey edited comment on QPID-6009 at 8/17/14 11:12 AM:
-------------------------------------------------------------

Personally I think the system properties are now redundant (although they are still used by
the tests - but we could actually fix that using context defaulting I think).

As you state we can allow configuration at the port level by restricting the available protocols,
and if a system administrator wishes to remove a protocol entirely they can simply remove
the protocol plugin (admittedly that doesn't give you the ability to selectively remove 0-8,
0-9 or 0-9-1 while retaining the others - however given they similarity between these variants,
I'm not sure there is any real utility in removing only some of these at a system rather than
port level).

To expand on the test case scenario, currently our maven configuration has lines like the
following:

{code:xml}<profile.qpid.broker_default_amqp_protocol_excludes>AMQP_1_0,AMQP_0_10</profile.qpid.broker_default_amqp_protocol_excludes>
{code}

Instead I think we'd want to do something like

{code:xml}<profile.qpid.test.amqp_port_protocols>[ "AMQP_0_8" , "AMQP_0_9", "AMQP_0_9_1"
]</profile.qpid.test.amqp_port_protocols>
{code}

and then change the config-systests.json file to include something like:

{code:javascript}

  "ports" : [  {
    "name" : "amqp",
    "authenticationProvider" : "plain",
    "port" : "${test.port}",
    "protocols" : "${test.amqp_port_protocols}"
  },
{code}


was (Author: rgodfrey):
Personally I think the system properties are now redundant (although they are still used by
the tests - but we could actually fix that using context defaulting I think).

As you state we can allow configuration at the port level by restricting the available protocols,
and if a system administrator wishes to remove a protocol entirely they can simply remove
the protocol plugin (admittedly that doesn't give you the ability to selectively remove 0-8,
0-9 or 0-9-1 while retaining the others - however given they similarity between these variants,
I'm not sure there is any real utility in removing only some of these at a system rather than
port level).

> [Java Broker] Add meta data to managed attributes to provide information where valid
values are restricted
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: QPID-6009
>                 URL: https://issues.apache.org/jira/browse/QPID-6009
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Java Broker
>            Reporter: Rob Godfrey
>            Assignee: Rob Godfrey
>
> For some configured object types, the valid values for some attributes differ between
different implementation types (one example would be the valid combinations of protocols on
Ports).  Information on valid values for such attributes could be provided in the annotation
and then provided to the UI through the meta data servlet.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message