On 25 March 2013 20:57, Fraser Adams <fraser.ad...@blueyonder.co.uk> wrote:
> Hey Robbie, > Thanks for the comprehensive response - all useful stuff, always on the > bleeding edge me :-) > as in "it's not bleeding working again" :-D > > Sorry about that... but there is a reason we haven't declared a release to be 1.0 yet :-) > It's fun to know "I think you are the first to ever ask about a change ". > I guess that I had assumed that a plugin architecture was intended to be > used for erm plugins, I guess that I slightly wryly noted too that it had > only arrived in 0.20 so "imagine my surprise" when it changed again so > quickly :'( > > Going forward we are looking to have a stable plugin API. One of the problems with time bound released rather than functionality scoped releases is that you run the risk of getting a cut of a feature before it is fully matured... so is the case with the management changes in the Java Broker in 0.20 (and probably in 0.22 as well). > RE "Its a shame you werent tracking trunk as it may be too late to fix > some issues for the next release " yeah I've hitherto mainly been working > against official releases and I've just started tracking truck, as you > suggest I'd clearly have picked this up sooner had I been. It's no bigee > really as the QMF Management Plugin is built as a separate target. It was > an initial release 'cause a few people had been asking about it and being > able to control the Java broker from a CLI such as qpid-config. > > I've taken a look through some of the new plugin code. I did wonder when > this all changed if it was related to the config work you've been > mentioning elsewhere. > > I had a look at the new config.json file that gets put into the working > directory - where does the default one get generated from? I did a quick > grep but couldn't see what wrote out config.json if one doesn't already > exist. > > > Re "but I think you might find the changes are far more substantial than > just the plugin interface itself and those may pose bigger problems " what > sort of things are you alluding to here? My QMF plugin doesn't do anything > especially clever and you've clearly modded the JMX and HTTP plugins to the > new API. The bulk of the code beyond the "plugin" stuff just uses the > org.apache.qpid.server.model classes which don't (at a superficial glance) > appear to have changed radically. > > I guess I'll find out when I look further. > > Thanks again for the update. > > > One further question RE "remove the old XML configuration files, and make > the broker pretty much entirely configurable through the management > interfaces" what's the motivation behind this? Funnily enough one of the > things that I thought the Java broker had better than the C++ broker was > the ability to specify configuration a priori. In my experience there are > plenty of cases where one actually wants to provide a broker configuration > that has been configuration managed. We certainly do in my set up and it > rather irks me to have to essentially script qpid-config to configure our > brokers to bootstrap the system. Don't get me wrong the management > interfaces are great but the ability to have a configured config also seems > useful. One thing that bugs me with the C++ broker is that I can't make a > queue's configuration persistent without making the queue persistent (if > you see what I mean) what I actually want is for the queue to be re-created > automatically when the broker restarts but for messages to not be persisted > (I can't easily change the producer to mark the messages non-persistent). > I'm forced to use scripts to do this which is irksome. As I say the Java > broker supported doing this via the XML config, but it seems like you've > changed this - it seemed like a valid use-case so I'm interested to know > what the driver was. > > So one of the issues we had is that we previously had definitions in two places - the database and the config file. With two (or more) possible repositories for queue definition there is a question as to which one is the master. We are trying to unify this into a single (authoritative) place. For those who want to be able to hand-edit their config files we will provide a JSON representation (the format of the store should be pluggable - really! - so an XML format would also be possible)... Alternatively for those who want everything in a database, that will also be possible. It is a key requirement (to me at least) that config should be able to be stored in a purely text based form that can be hand edited (and extracted en-masse and replayed into a new instance). -- Rob > Frase > > > > On 25/03/13 13:53, Robbie Gemmell wrote: > >> Hi Fraser, >> >> What you have now noticed is a step in our ongoing effort to reorganise >> the >> broker internals, remove the old XML configuration files, and make the >> broker pretty much entirely configurable through the management >> interfaces. >> >> The particular plugable management interface you found and used with 0.20 >> was actually only introduced in 0.20, when we simplified the plugins from >> prior versions of the broker (which used a somewhat contorted plugin >> system >> via the XML and an embedded OSGi container). That change was a first step >> towards letting us work on removing the broker-level XML configuration >> (and >> ServerConfiguration along with it, being at the heart of that stuff). The >> core of that landed on trunk over a month ago, having been in progress on >> a >> branch since the end of October. >> >> Although the larger idea of the changes have been mentioned in general >> several times over the last year or more, I dont think we actually did >> specifically call out the difference in the pluggability, primarily >> because >> at the time the change was made (either months ago when it was, or more >> recently when it was merged) no other such plugins actually existed and >> weren't really expected to. >> >> I'm afraid to say the answer to your question around stability is no, at >> least as far as the particular bit you are probably asking about is >> concerned, i.e the way the jmx and http management plugins are currently >> loading. That happens to be something that was done as a means to make it >> work with the new configuration, but exactly how it does is a source of >> annoyance and rather likely to change again. >> >> We can possibly look to improve things for 0.22 if there is somethign >> simple that would help, but I think you might find the changes are far >> more >> substantial than just the plugin interface itself and those may pose >> bigger >> problems. Its a shame you werent tracking trunk as it may be too late to >> fix some issues for the next release. I havent managed to take a proper >> look at what you did, though a quick skim does leave me with a few >> questions so I'll try to do so. >> >> I guess the take away point is that the pluggability has generally been >> there as much as an after thought than anything else, and maintaining >> compatibility between reelases has not been a priority as we have no >> plugins that target multiple releases and so few people (besides us, I >> think I recall 3 people including you mentioning it over the years) have >> ever used the pluggability we didn't really expect it to be an issue yet >> (and I think you are the first to ever ask about a change). I see you >> noted >> in your readme the pluggable points have never been documented; thats true >> and our intention with these ongoing changes is very much to document such >> things, once they become stable. >> >> Robbie >> >> On 24 March 2013 16:53, Fraser Adams <fraser.ad...@blueyonder.co.uk**> >> wrote: >> >> I put together a QmfManagementPlugin for the Java Broker using the plugin >>> API >>> >>> org.apache.qpid.server.plugin.****ManagementFactory >>> org.apache.qpid.server.****management.plugin.****ManagementPlugin >>> >>> This works nicely for Qpid 0.20 but I've just tried to build against >>> trunk >>> and those interfaces have gone :'( >>> >>> Looks like org.apache.qpid.server.****configuration.**** >>> ServerConfiguration >>> has gone too. >>> >>> >>> Looks like there's a new plugin API, what gives?? It's a little bit >>> frustrating - was this change mentioned anywhere (Jira?) I must have >>> missed >>> it. >>> >>> I've not had much of a change to look at the new plugin API, is this >>> likely to be vaguely stable? >>> >>> Any info gratefully received. >>> >>> Cheers, >>> Frase >>> >>> ------------------------------****----------------------------** >>> --**--------- >>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.****org< >>> dev-unsubscribe@qpid.**apache.org <dev-unsubscr...@qpid.apache.org>> >>> For additional commands, e-mail: dev-h...@qpid.apache.org >>> >>> >>> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@qpid.apache.**org<dev-unsubscr...@qpid.apache.org> > > For additional commands, e-mail: dev-h...@qpid.apache.org > >
