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]
