"Kevin.Conner@jboss.com" wrote:
For example, someone sets this single parameters to 20 and it works fine with their current listeners. Then they add a new one, opposite type, but forget to 'downgrade' the value.
Do you not think that having two would make the difference obvious? You could support *both* values without having to force the user into using the lowest one, especially if that lower value happens to be 1.
I only think it will make it more obvious to the user (from a config perspective) if the user sees the 2 config params in front of him/her when they encounter the issue, or if they've already run into the issue some time before. I also don't think it would be any more obvious to the user than the option of creating another dedicated "one-session-per-connection" provider block and putting the bus configs for those in there in one place.
"Kevin.Conner@jboss.com" wrote:
We are trying to minimise impact, as this is a platform branch, so major rewrites are out. But this should be a small change which would have a big impact on usability. Do you not agree?
I don't disagree, as such ;) I would agree that in theory the change to accomodate this should be straightforward enough, but 2 factors weight against this in my mind... 1) I was under the impression that we were trying to make min changes here and that that would rule out anything that was not absolutely necessary, which I would consider this to be since the user has an "acceptable" (enough IMO) way around it... 2) the current impl is not as straightforward as it should/could be, so making seemingly trivial improvements on top of it would probably just obscure an already obscured chunk of code a little bit more IMO.
All that said, I think we could debate this until the cows come home, so why don't we say that I just add a second parameter and get on with it :)