> Or, alternatively, don't use the internal artemis anymore, and only rely on the external. That is probably even more work.
Assuming you're using managed resources (e.g. MDBs for consuming and pooled-connection-factory for sending) and don't have connection configuration details littered through your code then switching completely to an external broker should actually be pretty simple - just a matter of changing a bit of XML. In any case, I think the underlying issue with MQTT + Wildfly is probably fairly simple. It's just a matter of setting aside some time to reproduce the issue and dig into it. You could, of course, crack open the broker in the debugger yourself and take a peek. This is open-source after all. Contributions are always welcome. Justin On Fri, Sep 22, 2017 at 7:17 AM, thoutekier <thomas.houtek...@barco.com> wrote: > Hi Justin, > > I appreciate the suggestion, but I don't consider that an option. > What I want to do is expose the queues and topic of the internal jms-bus > over MQTT. JMS is used extensively in my application and I currently expose > access to those messages outside of the server using a http-wrapper: a > pub/sub implementation using long-polling. > I want to replace that with mqtt. > Adding an external broker next to wildfly just to have MQTT-support, adds > too much complexity: I'll have to synchronize the wildfly-internal jms-bus > with this external one, in both directions. > Or, alternatively, don't use the internal artemis anymore, and only rely on > the external. That is probably even more work. > Deployment doesn't become easier either. > So you see, even if it is possible, it isn't all that simple, so it doesn't > really help me :-) > > Bottomline is, if I can't get MQTT up and running in wildfly, I won't be > using it at all. > Thomas > > > > > -- > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User- > f2341805.html >
