Inquiry about how ActiveMQ has no support for settings and getters which existed in Legacy AMQ-5.x

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Inquiry about how ActiveMQ has no support for settings and getters which existed in Legacy AMQ-5.x

Martes Wigglesworth
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?
Reply | Threaded
Open this post in threaded view
|

Re: Inquiry about how ActiveMQ has no support for settings and getters which existed in Legacy AMQ-5.x

jbertram
>  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 <[hidden email]>
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?
>
Reply | Threaded
Open this post in threaded view
|

Re: Inquiry about how ActiveMQ has no support for settings and getters which existed in Legacy AMQ-5.x

Martes Wigglesworth
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 <[hidden email]>
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 <[hidden email]
> >
> 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: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Inquiry about how ActiveMQ has no support for settings and getters which existed in Legacy AMQ-5.x

Martes Wigglesworth
Sorry, (their implementation makes assumptions....)

On Mon, Oct 23, 2017 at 12:11 PM, Martes Wigglesworth <[hidden email]>
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 <[hidden email]>
> 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 <
>> [hidden email]>
>> 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: [hidden email]
>



--
Martes G Wigglesworth
Senior Middleware Consultant
Red Hat Consulting
Red Hat, Inc.
Office Phone: 804 343 6084 <callto:804%20343%206084> - 8136084
Office Email: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Inquiry about how ActiveMQ has no support for settings and getters which existed in Legacy AMQ-5.x

clebertsuconic
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
<[hidden email]> wrote:

> Sorry, (their implementation makes assumptions....)
>
> On Mon, Oct 23, 2017 at 12:11 PM, Martes Wigglesworth <[hidden email]>
> 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 <[hidden email]>
>> 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 <
>>> [hidden email]>
>>> 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: [hidden email]
>>
>
>
>
> --
> Martes G Wigglesworth
> Senior Middleware Consultant
> Red Hat Consulting
> Red Hat, Inc.
> Office Phone: 804 343 6084 <callto:804%20343%206084> - 8136084
> Office Email: [hidden email]



--
Clebert Suconic