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]

Reply via email to