You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by john dunning <jr...@redhat.com> on 2010/01/04 19:41:51 UTC
Test suite vs optional xml config
I'm squiffing up qpid-config to add the ability to configure xml
exchanges and queue bindings. I'm trying to add stuff to the test suite
(cpp/src/tests/cli_tests.py and related) to match.
The difficulty I have right now is that the xml support is optional. If
you didn't configure for xml and load the module when you started the
broker, you don't get xml support, and my test case flames out.
It's not too hard to make the wrapper script (run_cli_tests) sense the
presence of the module and only optionally add the --load-module arg.
Presumably something analogous could be done on windows as well. It's
less clear to me how to make the test code sense that the environment is
sans-xml and DTRT.
Possibilities which come to mind:
1. Trap the error (about xml being unhandled) and ignore it
2. Move the xml test out into a separate module, and only invoke it if
we're configured the right way.
3. Interrogate the broker to ask him if he does xml (is this even
possible?)
Anybody care to express an opinion on the cleanest way to make the test
suite seamlessly accomodate xml support? TIA...
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: Test suite vs optional xml config
Posted by Robbie Gemmell <ro...@gmail.com>.
Yep, supported Exchange types is something I exposed via the JMX interface
for the Java broker not so long ago, and is something I'd want available as
and when QMF support is added to it. As such adding it to the C++ broker
seems sensible, and more so considering it actually has custom exchange
types already in use.
Robbie
> -----Original Message-----
> From: Robert Godfrey [mailto:rob.j.godfrey@gmail.com]
> Sent: 04 January 2010 19:43
> To: dev@qpid.apache.org
> Subject: Re: Test suite vs optional xml config
>
> 2010/1/4 john dunning <jr...@redhat.com>
>
> > I'm squiffing up qpid-config to add the ability to configure xml
> > exchanges and queue bindings. I'm trying to add stuff to the test
> suite
> > (cpp/src/tests/cli_tests.py and related) to match.
> >
> > The difficulty I have right now is that the xml support is optional.
> If
> > you didn't configure for xml and load the module when you started the
> > broker, you don't get xml support, and my test case flames out.
> >
> > It's not too hard to make the wrapper script (run_cli_tests) sense
> the
> > presence of the module and only optionally add the --load-module arg.
> > Presumably something analogous could be done on windows as well.
> It's
> > less clear to me how to make the test code sense that the environment
> is
> > sans-xml and DTRT.
> >
> > Possibilities which come to mind:
> >
> > 1. Trap the error (about xml being unhandled) and ignore it
> > 2. Move the xml test out into a separate module, and only invoke it
> if
> > we're configured the right way.
> > 3. Interrogate the broker to ask him if he does xml (is this even
> > possible?)
> >
> >
> In the interests of making our test cases portable to other brokers
> (and in
> particular the Java Broker) i would really like to see some way of
> making
> this third option happen :-) Something to add to the things you can
> interrogate via QMF perhaps...
>
> -- Rob
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Test suite vs optional xml config
Posted by Alan Conway <ac...@redhat.com>.
On 01/04/2010 02:43 PM, Robert Godfrey wrote:
> 2010/1/4 john dunning<jr...@redhat.com>
>
>> I'm squiffing up qpid-config to add the ability to configure xml
>> exchanges and queue bindings. I'm trying to add stuff to the test suite
>> (cpp/src/tests/cli_tests.py and related) to match.
>>
>> The difficulty I have right now is that the xml support is optional. If
>> you didn't configure for xml and load the module when you started the
>> broker, you don't get xml support, and my test case flames out.
>>
>> It's not too hard to make the wrapper script (run_cli_tests) sense the
>> presence of the module and only optionally add the --load-module arg.
>> Presumably something analogous could be done on windows as well. It's
>> less clear to me how to make the test code sense that the environment is
>> sans-xml and DTRT.
>>
>> Possibilities which come to mind:
>>
>> 1. Trap the error (about xml being unhandled) and ignore it
>> 2. Move the xml test out into a separate module, and only invoke it if
>> we're configured the right way.
>> 3. Interrogate the broker to ask him if he does xml (is this even
>> possible?)
>>
>>
> In the interests of making our test cases portable to other brokers (and in
> particular the Java Broker) i would really like to see some way of making
> this third option happen :-) Something to add to the things you can
> interrogate via QMF perhaps...
>
You can declare an XML exchange and catch the exception if it fails.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Test suite vs optional xml config
Posted by Robert Godfrey <ro...@gmail.com>.
2010/1/4 john dunning <jr...@redhat.com>
> I'm squiffing up qpid-config to add the ability to configure xml
> exchanges and queue bindings. I'm trying to add stuff to the test suite
> (cpp/src/tests/cli_tests.py and related) to match.
>
> The difficulty I have right now is that the xml support is optional. If
> you didn't configure for xml and load the module when you started the
> broker, you don't get xml support, and my test case flames out.
>
> It's not too hard to make the wrapper script (run_cli_tests) sense the
> presence of the module and only optionally add the --load-module arg.
> Presumably something analogous could be done on windows as well. It's
> less clear to me how to make the test code sense that the environment is
> sans-xml and DTRT.
>
> Possibilities which come to mind:
>
> 1. Trap the error (about xml being unhandled) and ignore it
> 2. Move the xml test out into a separate module, and only invoke it if
> we're configured the right way.
> 3. Interrogate the broker to ask him if he does xml (is this even
> possible?)
>
>
In the interests of making our test cases portable to other brokers (and in
particular the Java Broker) i would really like to see some way of making
this third option happen :-) Something to add to the things you can
interrogate via QMF perhaps...
-- Rob
RE: Test suite vs optional xml config
Posted by Steve Huston <sh...@riverace.com>.
> On 01/06/2010 11:20 AM, john dunning wrote:
> > On Wed, 2010-01-06 at 16:11 +0000, Gordon Sim wrote:
> >> On 01/06/2010 04:05 PM, Alan Conway wrote:
> >
> >>> Thats true, but I think it is still worth splitting out test sets
> >>> for optional modules into separate files for the sake of
> clarity and
> >>> readability.
> >>
> >> Yes, thats a fair point.
> >
> > Thanks all. For the immediate goal (getting the new features into
> > qpid-config and adding tests for them) I'm going to go with
> the least
> > intrusive solution, which seems to be sensing the presence of the
> > xml.so and driving the rest of the infrastructure accordingly.
> >
> > There likely does deserve to be some followon work to split up the
> > test stuff in a more modular way.
> >
>
> Shoud have mentioned this earlier but the cluster module is
> an existing example
> of this. The way it works is
> - all cluster-specific build & test rules are in
> src/tests/cluster.mk
> - cluster.mk has the form "if HAVE_LIBCPG ... endif"
> - cluster.mk is included in Makefile.am
>
> The existing XML tests are handled similarly but they're not
> broken out into a
> separate .mk file as they're currently quite trivial. If you
> add a lot of tests
> then it might be worth breaking this out int xml.mk
The additions should also be in the cmake builds. We're supposed to
transition to cmake sometime post-0.6.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Test suite vs optional xml config
Posted by Alan Conway <ac...@redhat.com>.
On 01/06/2010 11:20 AM, john dunning wrote:
> On Wed, 2010-01-06 at 16:11 +0000, Gordon Sim wrote:
>> On 01/06/2010 04:05 PM, Alan Conway wrote:
>
>>> Thats true, but I think it is still worth splitting out test sets for
>>> optional modules into separate files for the sake of clarity and
>>> readability.
>>
>> Yes, thats a fair point.
>
> Thanks all. For the immediate goal (getting the new features into
> qpid-config and adding tests for them) I'm going to go with the least
> intrusive solution, which seems to be sensing the presence of the xml.so
> and driving the rest of the infrastructure accordingly.
>
> There likely does deserve to be some followon work to split up the test
> stuff in a more modular way.
>
Shoud have mentioned this earlier but the cluster module is an existing example
of this. The way it works is
- all cluster-specific build & test rules are in src/tests/cluster.mk
- cluster.mk has the form "if HAVE_LIBCPG ... endif"
- cluster.mk is included in Makefile.am
The existing XML tests are handled similarly but they're not broken out into a
separate .mk file as they're currently quite trivial. If you add a lot of tests
then it might be worth breaking this out int xml.mk
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Test suite vs optional xml config
Posted by john dunning <jr...@redhat.com>.
On Wed, 2010-01-06 at 16:11 +0000, Gordon Sim wrote:
> On 01/06/2010 04:05 PM, Alan Conway wrote:
> > Thats true, but I think it is still worth splitting out test sets for
> > optional modules into separate files for the sake of clarity and
> > readability.
>
> Yes, thats a fair point.
Thanks all. For the immediate goal (getting the new features into
qpid-config and adding tests for them) I'm going to go with the least
intrusive solution, which seems to be sensing the presence of the xml.so
and driving the rest of the infrastructure accordingly.
There likely does deserve to be some followon work to split up the test
stuff in a more modular way.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Test suite vs optional xml config
Posted by Gordon Sim <gs...@redhat.com>.
On 01/06/2010 04:05 PM, Alan Conway wrote:
> On 01/06/2010 06:14 AM, Gordon Sim wrote:
>> On 01/04/2010 06:41 PM, john dunning wrote:
>>> I'm squiffing up qpid-config to add the ability to configure xml
>>> exchanges and queue bindings. I'm trying to add stuff to the test suite
>>> (cpp/src/tests/cli_tests.py and related) to match.
>>>
>>> The difficulty I have right now is that the xml support is optional. If
>>> you didn't configure for xml and load the module when you started the
>>> broker, you don't get xml support, and my test case flames out.
>>>
>>> It's not too hard to make the wrapper script (run_cli_tests) sense the
>>> presence of the module and only optionally add the --load-module arg.
>>> Presumably something analogous could be done on windows as well. It's
>>> less clear to me how to make the test code sense that the environment is
>>> sans-xml and DTRT.
>>>
>>> Possibilities which come to mind:
>>>
>>> 1. Trap the error (about xml being unhandled) and ignore it
>>> 2. Move the xml test out into a separate module, and only invoke it if
>>> we're configured the right way.
>>> 3. Interrogate the broker to ask him if he does xml (is this even
>>> possible?)
>>>
>>> Anybody care to express an opinion on the cleanest way to make the test
>>> suite seamlessly accomodate xml support? TIA...
>>
>> Just a suggestion:
>>
>> The run_cli_tests script uses the qpid-python-test tool which allows an
>> ignore file to be specified. So you could detect the availability of the
>> module and load it if available as you say, and if not available specify
>> an ignore file that excludes the xml exchange related tests.
>>
>
> Thats true, but I think it is still worth splitting out test sets for
> optional modules into separate files for the sake of clarity and
> readability.
Yes, thats a fair point.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Test suite vs optional xml config
Posted by Alan Conway <ac...@redhat.com>.
On 01/06/2010 06:14 AM, Gordon Sim wrote:
> On 01/04/2010 06:41 PM, john dunning wrote:
>> I'm squiffing up qpid-config to add the ability to configure xml
>> exchanges and queue bindings. I'm trying to add stuff to the test suite
>> (cpp/src/tests/cli_tests.py and related) to match.
>>
>> The difficulty I have right now is that the xml support is optional. If
>> you didn't configure for xml and load the module when you started the
>> broker, you don't get xml support, and my test case flames out.
>>
>> It's not too hard to make the wrapper script (run_cli_tests) sense the
>> presence of the module and only optionally add the --load-module arg.
>> Presumably something analogous could be done on windows as well. It's
>> less clear to me how to make the test code sense that the environment is
>> sans-xml and DTRT.
>>
>> Possibilities which come to mind:
>>
>> 1. Trap the error (about xml being unhandled) and ignore it
>> 2. Move the xml test out into a separate module, and only invoke it if
>> we're configured the right way.
>> 3. Interrogate the broker to ask him if he does xml (is this even
>> possible?)
>>
>> Anybody care to express an opinion on the cleanest way to make the test
>> suite seamlessly accomodate xml support? TIA...
>
> Just a suggestion:
>
> The run_cli_tests script uses the qpid-python-test tool which allows an
> ignore file to be specified. So you could detect the availability of the
> module and load it if available as you say, and if not available specify
> an ignore file that excludes the xml exchange related tests.
>
Thats true, but I think it is still worth splitting out test sets for optional
modules into separate files for the sake of clarity and readability.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Test suite vs optional xml config
Posted by Gordon Sim <gs...@redhat.com>.
On 01/04/2010 06:41 PM, john dunning wrote:
> I'm squiffing up qpid-config to add the ability to configure xml
> exchanges and queue bindings. I'm trying to add stuff to the test suite
> (cpp/src/tests/cli_tests.py and related) to match.
>
> The difficulty I have right now is that the xml support is optional. If
> you didn't configure for xml and load the module when you started the
> broker, you don't get xml support, and my test case flames out.
>
> It's not too hard to make the wrapper script (run_cli_tests) sense the
> presence of the module and only optionally add the --load-module arg.
> Presumably something analogous could be done on windows as well. It's
> less clear to me how to make the test code sense that the environment is
> sans-xml and DTRT.
>
> Possibilities which come to mind:
>
> 1. Trap the error (about xml being unhandled) and ignore it
> 2. Move the xml test out into a separate module, and only invoke it if
> we're configured the right way.
> 3. Interrogate the broker to ask him if he does xml (is this even
> possible?)
>
> Anybody care to express an opinion on the cleanest way to make the test
> suite seamlessly accomodate xml support? TIA...
Just a suggestion:
The run_cli_tests script uses the qpid-python-test tool which allows an
ignore file to be specified. So you could detect the availability of the
module and load it if available as you say, and if not available specify
an ignore file that excludes the xml exchange related tests.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: Test suite vs optional xml config
Posted by Steve Huston <sh...@riverace.com>.
Hi John,
> I'm squiffing up qpid-config to add the ability to configure
> xml exchanges and queue bindings. I'm trying to add stuff to
> the test suite (cpp/src/tests/cli_tests.py and related) to match.
>
> The difficulty I have right now is that the xml support is
> optional. If you didn't configure for xml and load the
> module when you started the broker, you don't get xml
> support, and my test case flames out.
>
> It's not too hard to make the wrapper script (run_cli_tests)
> sense the presence of the module and only optionally add the
> --load-module arg.
Also, you can do this in cpp/src/CMakeLists.txt and/or
cpp/src/tests/CMakeLists.txt with the BUILD_XML setting - if XML is
being built, include the test, else not.
> Presumably something analogous could be done on windows as well.
Theoretically, yes, but since Windows doesn't today support the XML
exchange, you don't need to test this.
> It's less clear to me how to make
> the test code sense that the environment is sans-xml and DTRT.
>
> Possibilities which come to mind:
>
> 1. Trap the error (about xml being unhandled) and ignore it
Yes, if you could be sure it was because XML support isn't there.
> 2. Move the xml test out into a separate module, and only
> invoke it if we're configured the right way.
This is what I'd recommend.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org