Martin Ritchie wrote:
2009/7/8 Rafael Schloming <[email protected]>:
Aidan Skinner wrote:
On Wed, Jul 8, 2009 at 2:35 PM, Rafael Schloming<[email protected]>
wrote:
Aidan Skinner wrote:
On Wed, Jul 8, 2009 at 2:26 PM, Rafael Schloming<[email protected]>
wrote:
Why can't the java profile just do the same thing?
Lack of --data-dir. We should probably add that though. :)
Yes, especially if it would make the java profiles stop dumping things
like
derby.log and derbyDB outside the build dir. ;)
I thought I'd beaten that out of DerbyMessageStore. Are you still
seeing that running with java-derby?
It's definitely dumping derby.log into the root of the tree. It's possible
that the derbyDB dir was leftover from a while back. I've removed it and
will let you know if it reappears.
We have the ability to load a java broker configuration and modify it.
I would argue that we don't need a --data-dir option but simply need
to load the configuraiton file and set the work property to be the
value that would be set for --data-dir.
The config-systest-derby.xml just needs to have the environment-path
setup so it writes its files there by default rather than defaulting
to up QPID_WORK from the system properties.
Are you suggesting that it's a fundamentally bad idea to have a
--data-dir option or that it might simply be less work to change the way
QpidTestCase launches brokers?
Either way I'd strongly suggest that if we make any changes to the test
harness we really should take a step back and design a proper interface
between the test harness and the broker/broker-launcher/whatever.
QpidTestCase is something of a nexus of interdependencies between
hundreds of tests all with their own expectations running against two
different brokers, each with at least three different configurations.
Given this it's fairly delicate to make changes to the test harness, and
is always more work than expected. Factoring out the broker
start/clean/stop into a separate plugin might help isolate some of this,
and would permit a relatively clean way to use completely different code
to launch the different brokers.
Of course I'm forced to wonder if it's a good thing that we might
require such different code to launch the different brokers. Currently
the "interface", ad-hoc as it may be, is based on shell commands, so it
sort of raises a red flag for me that you can't launch the java broker
in the desired way with a simple shell command.
This brings me back to the Change in DerbyMessageStore to pick up
QPID_WORK directly which I don't agree this is correct. if the
environment path is not set for Derby then the broker should fail to
start up.
I don't know about this change, but it does seem like the configuration
of persistent resources for the java broker needs some thinking through.
Probably the cpp broker as well, last I checked it automatically creates
a data-dir in your home directory if you don't specify one, and IMHO
that's not particularly good form.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
