I think Rob might have applied that patch on trunk yesterday, if so it should now be in the latest nightly broker release archive at: https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Artefact-Release/lastSuccessfulBuild/artifact/trunk/qpid/java/broker/release/
Alternatively, you can build your own verison by running 'ant release-bin' (adding -Doptional=true if you want the optional bdbstore included) in qpid/java and then looking in qpid/java/broker/release qpid-all.jar is an [annoyingly named] manifest jar, it has no code in it and I can believe it probably doenst have the main-file set. As Rob suggests, you can start the broker using the scripts. Although it wont account for this new addition, you might find the the broker docs useful at: http://qpid.apache.org/releases/qpid-0.24/java-broker/book/index.html Robbie On 6 January 2014 17:31, Kyle Crumpton (kcrumpto) <kcrum...@cisco.com>wrote: > Hi Rob, Sorry for the really late reply / hope you remember this thread. > > I got some assistance from the irc. I pulled the latest source using "svn > checkout http://svn.apache.org/repos/asf/qpid/trunk/qpid qpid" > Then I ran "patch -i QPID-5437.patch --dry-run -p0" in the Java branch. > The patch seemed successful. From there I did an "ant build" and got the > file "qpid-all.jar" > Looking for where I would go from here to get this running and bound to a > different IP? > > I am finding that when I run it there is no main class specified. > > On 12/19/13 6:11 PM, "Rob Godfrey" <rob.j.godf...@gmail.com> wrote: > > >I've created https://issues.apache.org/jira/browse/QPID-5437 and attached > >a > >quick patch to allow for HTTP ports to be bound to a speicifc address in > >the same way that AMQP ports are. The patch is against the head of trunk > >rather than 0.22, though I don't imagine it'd be too difficult to get it > >to > >apply to that version. > > > >Hope this helps, > >Rob > > > > > >On 20 December 2013 00:51, Robbie Gemmell <robbie.gemm...@gmail.com> > >wrote: > > > >> On 19 December 2013 23:36, Rob Godfrey <rob.j.godf...@gmail.com> wrote: > >> > >> > So it looks like it will be a completely trivial fix to allow the HTTP > >> port > >> > to bind to different interfaces... the JMX (as Robbie says) not so > >> much... > >> > however if you don't need the JMX management plugin you can disable > >>it. > >> > > >> > >> It shouldnt be too much harder to implement for the JMX ports either, it > >> would likely just need use of some custom RMIServerSocketFactory > >> implementations, something we already do for other reasons (e.g > >> QpidSslRMIServerSocketFactory to allow use of SSL config other than the > >>JVM > >> default) > >> > >> The bit I was speaking to earlier is that the interfaces JMX listens on > >>are > >> completely distinct from the single IP/host it can actually advertise > >>the > >> JMXConnectorServer as being available at in the registry. > >> > >> > >> > > >> > If we patch up the HTTP management then all you'll need to do is > >>change > >> the > >> > initial config file to be populated with something like > >>"bindingAddress": > >> > "${openshift.app_ip}" and then modify the qpid start script to set > >>that > >> > config parameter from the environment. > >> > > >> > > >> You can pass "-Dfoo=bar" type values via the QPID_OPTS environment > >>variable > >> the script makes available. > >> > >> > >> > Obviously if you are giving the users access to the http management > >>then > >> > they might try to do things like add more ports to the broker, and > >>then > >> if > >> > they don't similarly restrict themselves to binding to only their > >>given > >> > address then you'd get conflicts... You could - I imagine prevent this > >> > either through locking down the Qpid config somewhat, or maybe at the > >> Linux > >> > level... > >> > > >> > If you're willing to run a patched version of the code I can probably > >> send > >> > you a patch by tmr which will allow the HTTP port to be bound to a > >> specific > >> > address in the same way that the AMQP port is. > >> > > >> > Hope this helps, > >> > Rob > >> > > >> > > >> > On 20 December 2013 00:26, Kyle Crumpton (kcrumpto) > >><kcrum...@cisco.com > >> > >wrote: > >> > > >> > > Hi Keith, Rob. > >> > > > >> > > Thank you for your replies. > >> > > I am actually at a point where I am trying to get qpid running on a > >> PaaS > >> > > instance in a linux container. > >> > > > >> > > Scenario is > >> > > User creates app: test in namespace test > >> > > domain is example.com > >> > > so you create this app on your PaaS which exists on your server: > >> > > "node1.example.com" > >> > > So what will happen is you have a bind server which will create an > >> entry: > >> > > test-test.example.com CNAME IN node1.example.com > >> > > This app will be spawned with an attribute OPENSHIFT_<APP_TYPE>_IP > >> which > >> > > will allow the user to bind to that IP instead of 127.0.0.1 which > >>would > >> > > just steal the port from the host machine. > >> > > So for example, test-test.example.com could have an IP 127.1.2.3; > >> > > Another user could create their own app too, say "test2" which would > >> also > >> > > be allocated a different IP address on the node1.example.com > >>machine. > >> > > This server is then treated as a gateway to your app which exists > >>on a > >> > > linux container. From here I'd want the user to be able to "add" > >>qpid > >> to > >> > > the app. > >> > > > >> > > So right now what would happen is, the main server, > >>node1.example.comis > >> > > running an http interface on port 8080 already. This will fail with > >>an > >> > > invalid port. I know you can configure the port, but that does not > >>seem > >> > to > >> > > be the proper way to handle the problem? > >> > > > >> > > Say you have 3 users who want to use qpid on their 3 respective > >>apps.. > >> It > >> > > seems that it'd be better to bind to the same ports on different IPs > >> then > >> > > to different ports on the same IP. > >> > > > >> > > Any thoughts? > >> > > > >> > > On 12/19/13 5:18 PM, "Keith W" <keith.w...@gmail.com> wrote: > >> > > > >> > > >Hello Kyle, > >> > > > > >> > > >Yes, this is supported. You can make the AMQP port bind to a > >> > > >particular interface using the binding address attribute. Use > >>the > >> > > >Web Management Console to edit the AMQP port and specify a binding > >> > > >address (127.1.244.129 in your case). Once done, restart the > >>Broker > >> > > >for that change to take effect. > >> > > > > >> > > >The Java Broker docs describe the process of editing the port. > >> > > > > >> > > > > >> > > > >> > > >> > >> > http://qpid.apache.org/releases/qpid-0.22/java-broker/book/Java-Broker-Po > >>r > >> > > >ts.html#Java-Broker-Ports-Configuring > >> > > > > >> > > >You can't yet specify a binding address for HTTP Management or JMX. > >> > > > > >> > > >Hope this helps. > >> > > > > >> > > > > >> > > > > >> > > > > >> > > >On 19 December 2013 21:18, Ted Ross <tr...@redhat.com> wrote: > >> > > >> Sorry Kyle, > >> > > >> > >> > > >> Gordon and I are giving you information about the C++ broker, not > >> the > >> > > >>Java > >> > > >> broker. I will need to defer to one of the Java broker folks to > >> > answer > >> > > >>for > >> > > >> that component. > >> > > >> > >> > > >> -Ted > >> > > >> > >> > > >> > >> > > >> On 12/19/2013 04:03 PM, Kyle Crumpton (kcrumpto) wrote: > >> > > >>> > >> > > >>> Hi Ted. I am using version 0.22. I actually got qpid from tar: > >> > > >>> qpid-java-broker-0.22.tar.gz > >> > > >>> > >> > > >>> On 12/19/13 3:00 PM, "Ted Ross" <tr...@redhat.com> wrote: > >> > > >>> > >> > > >>>> Kyle, > >> > > >>>> > >> > > >>>> That feature was added in release 0.20 > >> > > >>>> (https://issues.apache.org/jira/browse/QPID-3351). You may be > >> > using > >> > > >>>>an > >> > > >>>> older version. > >> > > >>>> > >> > > >>>> -Ted > >> > > >>>> > >> > > >>>> On 12/19/2013 03:15 PM, Kyle Crumpton (kcrumpto) wrote: > >> > > >>>>> > >> > > >>>>> Hi. I did this and I got the error: Unrecognized option: > >> > --interface > >> > > >>>>> > >> > > >>>>> On 12/19/13 12:59 PM, "Gordon Sim" <g...@redhat.com> wrote: > >> > > >>>>> > >> > > >>>>>> On 12/19/2013 06:45 PM, Kyle Crumpton (kcrumpto) wrote: > >> > > >>>>>>> > >> > > >>>>>>> I am just curious if there is a way to bind qpid to an IP > >>such > >> as > >> > > >>>>>>> 127.1.244.129 > >> > > >>>>>>> > >> > > >>>>>>> The reason I ask is I'm looking to deploy many instances to > >>a > >> > PaaS > >> > > >>>>>>>and > >> > > >>>>>>> will need multiple running instances. This is not possible > >>if > >> > > >>>>>>> everything > >> > > >>>>>>> tries to bind to localhost:8080. > >> > > >>>>>>> > >> > > >>>>>>> Does anyone know of a way to configure this? I could not > >>find > >> in > >> > > >>>>>>>the > >> > > >>>>>>> qpid documentation. > >> > > >>>>>> > >> > > >>>>>> Yes, you can use --interface to restrict the interfaces qpidd > >> will > >> > > >>>>>>bind > >> > > >>>>>> on. > >> > > >>>>>> > >> > > >>>>>> > >> > > >>>>>> > >> > > > >> > > >> > >>>>>>>>------------------------------------------------------------------- > >>>>>>>>-- > >> > > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > >> > > >>>>>> For additional commands, e-mail: dev-h...@qpid.apache.org > >> > > >>>>>> > >> > > >>>>> > >> > --------------------------------------------------------------------- > >> > > >>>>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > >> > > >>>>> For additional commands, e-mail: dev-h...@qpid.apache.org > >> > > >>>>> > >> > > >>>> > >> > > >>>> > >> > --------------------------------------------------------------------- > >> > > >>>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > >> > > >>>> For additional commands, e-mail: dev-h...@qpid.apache.org > >> > > >>>> > >> > > >>> > >> > > >>> > >> --------------------------------------------------------------------- > >> > > >>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > >> > > >>> For additional commands, e-mail: dev-h...@qpid.apache.org > >> > > >>> > >> > > >> > >> > > >> > >> > > >> > >> --------------------------------------------------------------------- > >> > > >> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > >> > > >> For additional commands, e-mail: dev-h...@qpid.apache.org > >> > > >> > >> > > > > >> > > > >>>--------------------------------------------------------------------- > >> > > >To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > >> > > >For additional commands, e-mail: dev-h...@qpid.apache.org > >> > > > > >> > > > >> > > > >> > > > >>--------------------------------------------------------------------- > >> > > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > >> > > For additional commands, e-mail: dev-h...@qpid.apache.org > >> > > > >> > > > >> > > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > >
