[
https://issues.apache.org/jira/browse/AMQ-7309?focusedWorklogId=633835&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-633835
]
ASF GitHub Bot logged work on AMQ-7309:
---------------------------------------
Author: ASF GitHub Bot
Created on: 04/Aug/21 21:20
Start Date: 04/Aug/21 21:20
Worklog Time Spent: 10m
Work Description: gemmellr commented on pull request #682:
URL: https://github.com/apache/activemq/pull/682#issuecomment-892982659
>
> * @gemmellr to suggest a test (either before or after matt adds the
tests) that could cover the use case in a clear/concise manner (e.g.
Build/Operate/Check), that would move the convo forward
>
I have described more than once, and shown a literal code example of what to
do for a test of this issue, which is utterly trivial. Ssend the JMS Message
objects from 5.x through a foriegn JMS 2 provider impl. Any that implements
what the JMS 2 spec says and as a result tries to apply the mandated value to
the original message (using the vendor-neutral Message API in place
specifically to let it do so) will fail.
>
> (admittedly as a passive watcher of this PR, I'm having a hard time
following your suggestions, i.e. understanding how the implementation of
delivery delay that _does not_ throw exceptions in the case of trying to mutate
or access data that isn't supported could provide return values with meaning,
Because those Message methods are not really a core part of the
implementation of Delivery Delay in 5.x itself, which is really part of the
producer impl. They have nothing to do with the behaviour applied by 5.x during
send, as was noted during this discussion. They are specifically there to
ensure foreign providers can record the values _they_ are applying with _their_
support. Anything should be able to call the 5.x message setJMSDeliveryTime and
getJMSDeliveryTime methods and expect it to work, regardless whether the 5.x
producer actually supports configuring a delivery delay.
> and the linked test case I'm assuming is failing due to this
implementation decision:
https://github.com/apache/qpid-jms/blob/6775a2e027d8963cda4f1a7dc75b115c5def4d47/qpid-jms-client/src/main/java/org/apache/qpid/jms/JmsSession.java#L999
- in which case QPID could choose to catch the UOE in a similar manner)
No, thats what will happens before this PR, when the client takes steps to
let a JMS 1.1 message object be sent, because obviously it doesnt find the
relevant method implemented, it didnt exist. This PR adds the JMS 2.0 method
impl (which then throws), meaning the client actually finds it implemented and
will proceed to the lower section and actually calling it. Expecting it to work
and not throw UOE, because theres really no reason a simple set/get of a
mandatory JMS header long value should ever throw. The Qpid JMS client will not
be catching UOE's to satisfy such behaviour from ActiveMQ, that in itself would
be incorrect.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 633835)
Time Spent: 8h (was: 7h 50m)
> Add JMS 2.0 support
> -------------------
>
> Key: AMQ-7309
> URL: https://issues.apache.org/jira/browse/AMQ-7309
> Project: ActiveMQ
> Issue Type: New Feature
> Components: Broker, JMS client
> Reporter: Jean-Baptiste Onofré
> Assignee: Jean-Baptiste Onofré
> Priority: Major
> Fix For: 5.17.0
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
