[
https://issues.apache.org/jira/browse/AMQ-7309?focusedWorklogId=633825&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-633825
]
ASF GitHub Bot logged work on AMQ-7309:
---------------------------------------
Author: ASF GitHub Bot
Created on: 04/Aug/21 20:46
Start Date: 04/Aug/21 20:46
Worklog Time Spent: 10m
Work Description: michaelandrepearce commented on pull request #682:
URL: https://github.com/apache/activemq/pull/682#issuecomment-892962330
It’s not about qpid its that you’re breaking cross protocol stuff. Qpid is
just showing those breaks up. The fact the activemq test didn’t pick up, is
just a miss but thankfully the qpid projects tests did.
I think it ties back to trying to fudge in jms 2.0 client side without
proper changes broker side, e.g. maybe this could be sorted by adding the
correct jms 2.0 mapping to AMQP broker side to sort correct protocol support.
Sent from my iPad
> On 4 Aug 2021, at 21:29, ehossack-aws ***@***.***> wrote:
>
>
> I'm wondering if a constructive way to move this conversation forward, and
JMS 2.0 support in general, would be to define a series of
JMS20CompatibilityTests, that utilize the APIs and act accordingly.
> The tests could assert that UOEs are thrown when expected, and certain
functionality works across 2.0 APIs when UOEs are not expected.
> A feature-complete reiteration of the JMS spec might not have value, but
there's certainly core areas that could be covered.
>
> As new support comes for methods (subtasks implemented of
https://issues.apache.org/jira/browse/AMQ-7309) those tests could be altered as
functional, and potentially all tests moved or relocated upon feature-complete
spec.
>
> That way too, we're talking about specific test cases in ActiveMQ and not
across QPID (valid to support though they may be).
> How does that sound? The action items there would be:
>
> @mattrpav to add a series of basic tests that cover the altered APIs
> @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
> (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,
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)
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or unsubscribe.
> Triage notifications on the go with GitHub Mobile for iOS or Android.
--
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: 633825)
Time Spent: 7.5h (was: 7h 20m)
> 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: 7.5h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
