[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    Re: Inquiry about how ActiveMQ has no support for settings and getters which existed in Legacy AMQ-5
From:       Clebert Suconic <clebert.suconic () gmail ! com>
Date:       2017-10-23 17:31:01
Message-ID: CAKF+bspD+aMKsxkv2oY9Z+U+5DwghJeSXHz3k1vd90z+A-1y+g () mail ! gmail ! com
[Download RAW message or body]

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
<mwiggles@redhat.com> wrote:
> 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



-- 
Clebert Suconic
[prev in list] [next in list] [prev in thread] [next in thread]