Last I was aware of things, the broker looked at the qpid.work_dir config property (see mention in my original mail), then if that isn't set populates it by looking at the QPID_WORK system property, then if that isn't set falls back to a 'work' subdir in the users home dir. The folks who have worked on the broker in the past couple years would better know the current state around this stuff though.
One thing to be careful of is that if you supply a pre-existing config file, it might contain paths that dont reference the work dir config variable. I guess it depends on what sort of isolation each of your tests needs whether that would be an issue. The alternative might be setting the option for the 'initial configuration' (essentially a template without the ID's etc) rather than just where the working config is to be saved, allowing the actual config to be created each time under the target dir along with the other related configuration/message data. Robbie On 3 February 2016 at 03:30, Alex O'Ree <[email protected]> wrote: > making great progress over here. I was able to resolve most of my > issues by grabbing the default json config file from the jar and the > etc files from the qpid distro. I could then star the embedded server > using the following code. > > org.apache.qpid.server.Broker broker2 = new Broker(); > BrokerOptions options = new BrokerOptions(); > options.setOverwriteConfigurationStore(true); > options.setStartupLoggedToSystemOut(true); > String file=new File(".").getAbsolutePath() + File.separator > + "config.json"; > options.setConfigurationStoreLocation(file); > broker2.startup(options); > > One last problem. I'm trying to redirect the location of the "work" > folder and put it into the maven target folder to make clean up a bit > easier. It's that's not possible, then i just use a maven plugin to > the job. > > > On Tue, Feb 2, 2016 at 12:44 PM, Robbie Gemmell > <[email protected]> wrote: >> Most things can be configured via the brokers http management >> interface, either via the web UI or by mimicking the calls it makes >> using other tools. The main thing to note with the latter is that HTTP >> basic-auth is disabled by default for, instead only working over HTTPS >> connections by default, so you would need to edit the httpManagement >> plugin options (either via the UI, or the config file) to enable that >> if you aren't using SSL. >> >> You can also edit the config.json saved by the broker (or supply your >> own initial config largely pre-configured). >> >> That said, I'm not sure why you would be seeing issue with the below >> since logging in with "guest:guest" worked out the box with 6.0.0 last >> I tried, and is what most of the system tests did last I looked. Any >> folks currently more familiar with these bits have an idea? >> >> Robbie >> >> On 2 February 2016 at 12:21, Alex O'Ree <[email protected]> wrote: >>> Ran into another related issue....is there a way to set the >>> authentication mode and/or ssl information programmatically? or should >>> I try to use the config file method? My client is supplying a password >>> using the following url >>> amqp://guest:guest@clientid/localhost?brokerlist='tcp://127.0.0.1:5672' >>> >>> >>> Caused by: org.apache.qpid.AMQException: Cannot connect to broker >>> (tcp://127.0.0.1:5672): CRAM-MD5 authentication failed [error code >>> 320: connection forced] >>> >>> On Mon, Feb 1, 2016 at 7:40 AM, Alex O'Ree <[email protected]> wrote: >>>> Robbie, >>>> >>>> spot on, that was it! thanks! I'm up and running >>>> >>>> On Mon, Feb 1, 2016 at 5:24 AM, Robbie Gemmell <[email protected]> >>>> wrote: >>>>> In Rob's earlier mail there was a typo in the example system property >>>>> setter so if you c&p it that could be the issue, it contained >>>>> "qpid.http.port" rather than "qpid.http_port". If not that, the >>>>> suggestion that there may be some stale prior config being picked up >>>>> seems likely. >>>>> >>>>> I'm not familiar with most of the work on the broker in the last >>>>> couple years, but back when the initial config for some things such as >>>>> the ports were made configurable via named properties support was >>>>> added to the BrokerOptions for influencing them (and any other user >>>>> defined config props). One of the properties used in the intial config >>>>> was also the work dir where configuration etc gets saved under, so >>>>> using that you could configure things to store under the maven target >>>>> dir for later cleanup. As I say its a while since I knew the current >>>>> details and I haven't tried this recently, but back then I'd have been >>>>> thinking about something like: >>>>> >>>>> BrokerOptions options = new BrokerOptions(); >>>>> options.setConfigProperty("qpid.work_dir", <path.to.target/subdir>); >>>>> options.setConfigProperty("qpid.amqp_port", <port>); >>>>> options.setConfigProperty("qpid.http_port", <port>); >>>>> ...etc.. >>>>> >>>>> Robbie >>>>> >>>>> On 1 February 2016 at 08:09, Rob Godfrey <[email protected]> wrote: >>>>>> Can you give the full stack trace... also are you cleaning up after >>>>>> running >>>>>> this, or is there a config.json from a previous run now written somewhere >>>>>> (on startup the broker will, by default, write out a config file based on >>>>>> the initial config, and in subsequent runs it will use the written file >>>>>> rather than the default). >>>>>> >>>>>> Thx, >>>>>> Rob >>>>>> >>>>>> On 1 February 2016 at 00:02, Alex O'Ree <[email protected]> wrote: >>>>>> >>>>>>> Ahh, there it is >>>>>>> >>>>>>> Caused by: java.net.BindException: Address already in use >>>>>>> >>>>>>> On Sun, Jan 31, 2016 at 6:47 PM, Rob Godfrey <[email protected]> >>>>>>> wrote: >>>>>>> > Nope - "no uncaught exception handler set" means exactly what it says >>>>>>> > :-) >>>>>>> > There's a JIRA for this >>>>>>> > https://issues.apache.org/jira/browse/QPID-6950 >>>>>>> which >>>>>>> > is fixed on trunk and the 6.0.x branch. >>>>>>> > >>>>>>> > If you set the default uncaught exception handler ( >>>>>>> > >>>>>>> https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#setDefaultUncaughtExceptionHandler(java.lang.Thread.UncaughtExceptionHandler) >>>>>>> > ) you should make some progress. >>>>>>> > >>>>>>> > -- Rob >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > On 31 January 2016 at 23:31, Alex O'Ree <[email protected]> wrote: >>>>>>> > >>>>>>> >> Thanks Rob! Appreciate the help >>>>>>> >> >>>>>>> >> Unfortunately, after setting the property, it didn't make any >>>>>>> >> difference. Still trying to start on 8080. >>>>>>> >> >>>>>>> >> Any clues? Is there a way to disable the management website? >>>>>>> >> >>>>>>> >> This the last excepting printed to stdout. I'm pretty sure that "no >>>>>>> >> uncaught exception handler set" means there's a port conflict, >>>>>>> >> because >>>>>>> >> tomcat is definitely running on that port >>>>>>> >> >>>>>>> >> Caused by: java.lang.IllegalStateException: no uncaught exception >>>>>>> handler >>>>>>> >> set >>>>>>> >> >>>>>>> >> at >>>>>>> >> >>>>>>> org.apache.qpid.server.management.plugin.filter.ExceptionHandlingFilter.init(ExceptionHandlingFilter.java:50) >>>>>>> >> >>>>>>> >> at >>>>>>> >> org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:118) >>>>>>> >> >>>>>>> >> at >>>>>>> >> >>>>>>> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64) >>>>>>> >> >>>>>>> >> at >>>>>>> >> >>>>>>> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:768) >>>>>>> >> >>>>>>> >> at >>>>>>> >> >>>>>>> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:265) >>>>>>> >> >>>>>>> >> at >>>>>>> >> >>>>>>> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:717) >>>>>>> >> >>>>>>> >> at >>>>>>> >> >>>>>>> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64) >>>>>>> >> >>>>>>> >> at >>>>>>> >> >>>>>>> org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:95) >>>>>>> >> >>>>>>> >> at org.eclipse.jetty.server.Server.doStart(Server.java:282) >>>>>>> >> >>>>>>> >> at >>>>>>> >> >>>>>>> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64) >>>>>>> >> >>>>>>> >> at >>>>>>> >> >>>>>>> org.apache.qpid.server.management.plugin.HttpManagement.doStart(HttpManagement.java:163) >>>>>>> >> >>>>>>> >> >>>>>>> >> On Sun, Jan 31, 2016 at 5:20 PM, Rob Godfrey >>>>>>> >> <[email protected]> >>>>>>> >> wrote: >>>>>>> >> > You're not starting in management mode (and you probably don't >>>>>>> >> > want to >>>>>>> >> :-) >>>>>>> >> > ), so setting the management port overrides is not really what you >>>>>>> want. >>>>>>> >> > >>>>>>> >> > Making the Broker easier to embed and start programmatically for >>>>>>> >> > unit >>>>>>> >> > tests, etc... is on my personal roadmap (I even have some work >>>>>>> somewhere >>>>>>> >> on >>>>>>> >> > my laptop that I should dig out), but for the moment, you can alter >>>>>>> the >>>>>>> >> > ports that are used on startup by either creating your own initial >>>>>>> config >>>>>>> >> > file, or simply by setting system properties. >>>>>>> >> > >>>>>>> >> > The default initial config file can be seen here: >>>>>>> >> > >>>>>>> >> >>>>>>> http://svn.apache.org/repos/asf/qpid/java/tags/6.0.0/broker-core/src/main/resources/initial-config.json >>>>>>> >> > >>>>>>> >> > In particular the following lines are of interest in terms of >>>>>>> >> > ports: >>>>>>> >> > >>>>>>> >> > "port" : "${qpid.amqp_port}", >>>>>>> >> > >>>>>>> >> > and... >>>>>>> >> > >>>>>>> >> > "port" : "${qpid.http_port}", >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > (By default in Qpid 6.0, the JMX ports are not enabled/created.) >>>>>>> >> > >>>>>>> >> > So, to set the HTTP port to 9090, you could just do >>>>>>> >> > >>>>>>> >> > System.setProperty("qpid.http.port", "9090"); >>>>>>> >> > >>>>>>> >> > before starting up the broker. >>>>>>> >> > >>>>>>> >> > For proper unit testing you'd probably want a different initial >>>>>>> >> > config >>>>>>> >> > using in-memory stores / config. You might also want to set the >>>>>>> ports to >>>>>>> >> > use to be port 0 (which will allocate a random free port). >>>>>>> >> > >>>>>>> >> > Hope this helps, >>>>>>> >> > Rob >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > On 31 January 2016 at 22:09, Alex O'Ree <[email protected]> >>>>>>> >> > wrote: >>>>>>> >> > >>>>>>> >> >> I've made some progress using 6.0.0. >>>>>>> >> >> >>>>>>> >> >> org.apache.qpid.server.Broker broker = new Broker(); >>>>>>> >> >> BrokerOptions options = new BrokerOptions(); >>>>>>> >> >> options.setManagementModeHttpPortOverride(9090); >>>>>>> >> >> options.setManagementModeJmxPortOverride(9099); >>>>>>> >> >> options.setManagementMode(false); >>>>>>> >> >> options.setStartupLoggedToSystemOut(true); >>>>>>> >> >> broker.startup(options); >>>>>>> >> >> >>>>>>> >> >> >>>>>>> >> >> The issue is that I have a port conflict on port 8080 and setting >>>>>>> >> >> the >>>>>>> >> >> ManagementModeHttpPortOverride doesn't seem to be honored. Any >>>>>>> >> >> ideas? >>>>>>> >> >> >>>>>>> >> >> On Sun, Jan 31, 2016 at 4:07 PM, Alex O'Ree <[email protected]> >>>>>>> >> wrote: >>>>>>> >> >> > I'm working on a project that needs to fire up a qpid java >>>>>>> >> >> > broker, >>>>>>> >> >> > send some messages, wait for replies, then shutdown, in the >>>>>>> context of >>>>>>> >> >> > a java unit test in maven. I saw that this used to be possible >>>>>>> >> >> > on >>>>>>> SO >>>>>>> >> >> > at one point. Anyhow, is there any examples on how to do this? >>>>>>> Perhaps >>>>>>> >> >> > I could reuse one of the existing unit tests from qpid? >>>>>>> >> >> >>>>>>> >> >> --------------------------------------------------------------------- >>>>>>> >> >> To unsubscribe, e-mail: [email protected] >>>>>>> >> >> For additional commands, e-mail: [email protected] >>>>>>> >> >> >>>>>>> >> >> >>>>>>> >> >>>>>>> >> --------------------------------------------------------------------- >>>>>>> >> To unsubscribe, e-mail: [email protected] >>>>>>> >> For additional commands, e-mail: [email protected] >>>>>>> >> >>>>>>> >> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
