I believe you will still be able to use them through the --argument option, which allows you to to define whatever parameter, or? But any scripts using the old parameters will need to be modified.
The qpid-config tool has a bit strange interface, as some of the options are accessible directly and some require the use of the --argument option. The best would be to use only the --argument options for everything, as that seems to allow quite a lot of flexibility for configuring objects and properties the qpid-config it self has no idea about. Jakub On Fri, Apr 11, 2014 at 7:37 PM, Justin Ross <[email protected]> wrote: > Fraser, you're right. I think this request is just going to the wrong > place. This change cannot go to trunk until the legacystore is deprecated > and then removed. Even then, it may be worth keeping the options around in > a less visible fashion to support deployments with the older store. > > > On Fri, Apr 11, 2014 at 1:29 PM, Fraser Adams < > [email protected] > > wrote: > > > OK so I'm going to bite. > > > > is legacystore as its name suggests going to be deprecated? At the moment > > there seems to be two stores, neither of which seem to have any > > documentation that a user might reasonably use in order to figure out how > > on earth to get persistence to work with qpidd. Well that was the case a > > few weeks ago when I last looked, if it has improved then I apologise for > > the rant :-) > > > > I'd personally prefer holding fire on removing things from qpid-config > and > > invest the energy in getting the documentation for qpidd persistence > into a > > decent state (including something on the whys and wherefores of > legacystore > > and linearstore). > > > > Moreover removing these options will instantly prevent this and > subsequent > > versions of qpid-config from being able to control these parameters on an > > older broker (have you considered use cases where users have a mixed > > economy of brokers? that's pretty common in my experience). > > > > I personally think it's a bit unfriendly to be removing features without > > providing a deprecation notice (and the intention of this work should > have > > been posted on to the user list). I might have missed it but I don't > recall > > seeing anything about this on the user list or on a Jira? > > > > Sorry if this seems a bit shirty :-) for context I have a very large > > federated system and generally there are a couple of different versions > > despite my best intentions, I've been bitten in the past by qpid-config > > changes. > > > > I don't generally use persistence with qpidd myself, so parochially I'm > > not affected, but I do think that there's a principal here with respect > to > > the wider community. > > > > Regards, > > Frase > > > > > > > > On 11/04/14 17:36, Ernie Allen wrote: > > > >> ----------------------------------------------------------- > >> This is an automatically generated e-mail. To reply, visit: > >> https://reviews.apache.org/r/20262/ > >> ----------------------------------------------------------- > >> > >> Review request for qpid, Gordon Sim and Ted Ross. > >> > >> > >> Repository: qpid > >> > >> > >> Description > >> ------- > >> > >> Remove the two parameters --file-size and --file-count from qpid-config > >> > >> Currently, qpid-config allows specifying qpid.file_count and > >> qpid.file_size queue declare options, via --file-count / --file-size > >> command line options. These options become obsolete in 3.0 due to > >> linearstore, that does not offer/require similar parameters. > >> > >> Removing refereces to file-size / file-count in the broker will be in a > >> separate patch. > >> > >> > >> Diffs > >> ----- > >> > >> /trunk/qpid/tools/src/py/qpid-config 1586666 > >> > >> Diff: https://reviews.apache.org/r/20262/diff/ > >> > >> > >> Testing > >> ------- > >> > >> qpid-config --help | grep file- > >> <no output> > >> > >> > >> Thanks, > >> > >> Ernie Allen > >> > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
