[
https://issues.apache.org/jira/browse/ARTEMIS-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16093488#comment-16093488
]
ASF GitHub Bot commented on ARTEMIS-1276:
-----------------------------------------
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1407
>>> If it expired on client, how would it then get to DLQ queue on server?
There's a special protocol on OpenWire to tell the server the message
expired. On Artemis we would just reject the message and let the server deal
with it again.
Having said that, perhaps there's something wrong on treating that
message..so it's worth to check if it's a bug on that area.. or just a test
issue.
I didn't look into the details specifically to this test BTW: I was just
mentioning that I had cases like this where I had to tweak the test because of
that semantic change.
> [openwire-tests] Enable more OpenWire tests (from ActiveMQ 5)
> -------------------------------------------------------------
>
> Key: ARTEMIS-1276
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1276
> Project: ActiveMQ Artemis
> Issue Type: Test
> Components: OpenWire
> Affects Versions: 2.2.0
> Reporter: Jiri Danek
> Priority: Minor
>
> I've been looking into the currently disabled OpenWire tests, if there is a
> way to implement support for more of them and enable them.
> I believe I've made some progress on this front, so I'd wish to discuss
> 1) what is the endgame about these tests; do we want to eventually run them
> all, or is it expected to to ignore some?
> 2) what tests would be useful to enable now? I've been looking at them from
> the point of how easy it is to enable them, not how useful it is.
> 3) would it be ok to add mockito as a test dependency? it seems useful,
> because sometimes it is necessary to wrap something in ActiveMQ5 class, and
> doing a proxy avoids having to invoke superclass constructors (when the thing
> that needs to be implemented is a class and not an interface). Mockito is IMO
> nicer to use than using java.lang.reflect.Proxy.newProxyInstance directly.
> and propose PR based on that discussion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)