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
