[
https://issues.apache.org/activemq/browse/AMQ-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dejan Bosanac resolved AMQ-1326.
--------------------------------
Assignee: Dejan Bosanac
Resolution: Fixed
Patch applied (with a few more code improvements) in SVN revision 700405
> Move/Copy feature for web console
> ---------------------------------
>
> Key: AMQ-1326
> URL: https://issues.apache.org/activemq/browse/AMQ-1326
> Project: ActiveMQ
> Issue Type: Improvement
> Affects Versions: 5.0.0
> Reporter: Dejan Bosanac
> Assignee: Dejan Bosanac
> Fix For: 5.3.0
>
> Attachments: activemq-core.patch, activemq-web-console.patch
>
>
> I've added message copy and move funcionality to the web console. For now it
> is only applied to the message.jsp page, since I think it is not a good fit
> the browse page interface (we can add some bulk copy/move messages operations
> later).
> I'm not sure what's your opinion on JS confirmation dialogs, but I generally
> think we should have some kind of user confirmation for operations such as
> delete, copy, move, etc (queues, topics, messages, ...) . I've added some JS
> code for these new operations and would provide additional confirmations for
> existing operations if it is OK with you. I've put all JS code in the
> common.js as it seemed the most appropriate place for it (maybe we could
> create a new file for this kind of JS code, but I think it is not necessary).
> While working on this, I found a potential problem in activemq-core module. A
> patch for it is also attached to this issue. The bug scenario is as follows:
> 1. create two queues
> 2. send text message using the web console
> 3. try to copy/move the message
> the null pointer exception is thrown.
> the same code used to copy the message in a test case works fine.
> After investigating a bit, I found that problem is caused by the fact that
> message sent through web console has responseRequired property set to false
> and it is tried to be dispatched asynchronously using the context without a
> valid connection. I saw the code similar to the problematic is used elsewhere
> in the Queue.java class but only for expired messages, so I've added an
> additional condition. I'm not sure if it is valid patch, but it solved this
> particular problem. It would be good if someone could investigate this
> further.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
