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
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 :'(
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.
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 <[email protected]> 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:
[email protected].**org<[email protected]>
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
