activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martes Wigglesworth <mwigg...@redhat.com>
Subject Re: Inquiry about how ActiveMQ has no support for settings and getters which existed in Legacy AMQ-5.x
Date Mon, 23 Oct 2017 16:11:54 GMT
Sorry, (their implementation makes assumptions....)

On Mon, Oct 23, 2017 at 12:11 PM, Martes Wigglesworth <mwiggles@redhat.com>
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 <jbertram@apache.org>
> 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 <
>> mwiggles@redhat.com>
>> 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: mwiggles@redhat.com
>



-- 
Martes G Wigglesworth
Senior Middleware Consultant
Red Hat Consulting
Red Hat, Inc.
Office Phone: 804 343 6084 <callto:804%20343%206084> - 8136084
Office Email: mwiggles@redhat.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message