Feel free to send a PR If you need any method at the connection factory though. or any properties that are not exposed.
On Mon, Oct 23, 2017 at 12:11 PM, Martes Wigglesworth <[email protected]> wrote: > Sorry, (their implementation makes assumptions....) > > On Mon, Oct 23, 2017 at 12:11 PM, Martes Wigglesworth <[email protected]> > wrote: > >> Thanks for the succinct response, Justin. >> >> This basically answers my question completely. >> >> The implementation has made some assumptions that are not >> forward-compatible. >> >> Thanks so much for the quick response. >> >> >> On Mon, Oct 23, 2017 at 11:54 AM, Justin Bertram <[email protected]> >> wrote: >> >>> > the artemis implementation of ActiveMQConnectionFactory, and why the >>> setters and getters were removed? >>> >>> To be clear, the Artemis client implementation is 100% independent of the >>> 5.x client implementation so, technically speaking, no setters or getters >>> were removed. Also, it's worth noting that while Artemis has good feature >>> parity with the 5.x broker there has been no concerted effort toward API >>> compatibility between client implementations (of course excluding >>> standards >>> like JMS, JNDI, etc.). >>> >>> >>> > We are working on integration of AMQ with bigdata tools and they are >>> expecting >>> AMQ-Artemis to behave as old AMQConnectionFactory used to. >>> >>> I'm not sure this is a valid expectation. As mentioned previously the two >>> client implementations are separate and no guarantee of API compatibility >>> has been advertised. The URL is really an implementation detail, and >>> applications that rely on implementation details open themselves up to >>> incompatibilities when moving between implementations. In the specific >>> case of API compatibility I would strongly encourage users towards >>> standards wherever possible in lieu of relying on implementation details. >>> >>> That said, if there's a simple change that would bring value to the >>> Artemis >>> client implementation I think it would be accepted. >>> >>> >>> > Also, would this be more of a "user-list" post? >>> >>> Since this concerns the development of the broker (e.g. potential PR, >>> etc.) >>> the dev list is fine. >>> >>> >>> Justin >>> >>> On Mon, Oct 23, 2017 at 10:36 AM, Martes Wigglesworth < >>> [email protected]> >>> wrote: >>> >>> > Greetings Justin. >>> > >>> > Do you have any time to chat about the artemis implementation of >>> > ActiveMQConnectionFactory, and why the setters and getters were removed? >>> > >>> > We are working on integration of AMQ with bigdata tools and they are >>> > expecting AMQ-Artemis to behave as old AMQConnectionFactory used to. >>> > >>> > By this I am referencing the omission of an exposed interface for >>> setting >>> > and getting brokerURL. >>> > >>> > Any insight on this topic would be appreciated, since I looked at a >>> patch >>> > and it required either a legacy named wrapper of >>> ActiveMQConnectionFactory, >>> > or ActiveMQJMSConnectionFactory, to re-insert the setBrokerURL and >>> > getBrokerURL. >>> > >>> > I figured this would get a huge "heck-no" from the team if I attempted >>> to >>> > create an issue, and submit a pull request, so I wanted to verify the >>> > situation before moving forward. (This is due to NiagraFiles requiring >>> > access to the brokerURL property, because of the assumed accessor >>> methods >>> > which existed in AMQ prior to artemis.) >>> > >>> > Is there an internal AMQ dev list that I can get on, at RH? >>> > >>> > I was reading through the user-list just now, and someone made >>> reference to >>> > the AMP specification, and how certain property are immutable due to >>> this >>> > specification. >>> > >>> > Is that possibly the source for the change in api? >>> > >>> > I am new to AMQ-Artemis source, so I may have missed some documented >>> reason >>> > for this change, and would appreciate any info, including a "RTFM" link. >>> > >>> > Also, would this be more of a "user-list" post? >>> > >>> >> >> >> >> -- >> Martes G Wigglesworth >> Senior Middleware Consultant >> Red Hat Consulting >> Red Hat, Inc. >> Office Phone: 804 343 6084 <callto:804%20343%206084> - 8136084 >> Office Email: [email protected] >> > > > > -- > Martes G Wigglesworth > Senior Middleware Consultant > Red Hat Consulting > Red Hat, Inc. > Office Phone: 804 343 6084 <callto:804%20343%206084> - 8136084 > Office Email: [email protected] -- Clebert Suconic
