You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Christian Schneider (JIRA)" <ji...@apache.org> on 2008/08/30 02:17:44 UTC
[jira] Created: (CXF-1773) Refactor JMS transport for readability
and simplicity (patch included)
Refactor JMS transport for readability and simplicity (patch included)
----------------------------------------------------------------------
Key: CXF-1773
URL: https://issues.apache.org/jira/browse/CXF-1773
Project: CXF
Issue Type: Improvement
Components: Transports
Affects Versions: 2.1.2
Reporter: Christian Schneider
Fix For: 2.1.3
In preparation for the planned improvements for JMS config like discussed on the mailing list the JMS transport should be refactored for readability.
I have worked myself into the JMS code and at the start had some problems understanding what happened because of some structures in the code.
The first thing was JMSTransportBase. Most of the class are methods that do not access any attributes. These methods could be made static and moved to the JMSUtil class. The method isDestinationStyleQueue is the only method that needs an attribute. I think it should have this attribute as a parameter and also be made static and moved to JMSUtils.
The rest of JMSTransportBase are only holders for attributes that are then accessed from JMSConduit and JMSDestination directly (even without getters). So I think the whole class could be dumped and to attributes should be moved to the subclasses. The readability of JMSConduit and JMSDestination is much better afterwards as the class can be understood in itself.
The next thing is JMSTransport which is used to feed JMSProviderHub. I think it should be cut down to the callback method connected and be renamed to JMSOnConnectCallBack. The other two methods can be added to the parameters of JMSProviderHub. The advantage is that it is much clearer what JMSProviderHub.connect needs and that connected is a callback that gets called at the end of connect.
I have already done the refactorings and will attach a patch with them. Checkstyle, PMD and surefire show no problems.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-1773) Refactor JMS transport for readability
and simplicity (patch included)
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp resolved CXF-1773.
------------------------------
Resolution: Fixed
Patch was applied. Resolving this issue. Please open new issues for new patches as needed.
Thanks!
Dan
> Refactor JMS transport for readability and simplicity (patch included)
> ----------------------------------------------------------------------
>
> Key: CXF-1773
> URL: https://issues.apache.org/jira/browse/CXF-1773
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Affects Versions: 2.1.2
> Reporter: Christian Schneider
> Assignee: Willem Jiang
> Fix For: 2.1.3
>
> Attachments: cxf-1773-refactor-jms.patch
>
>
> In preparation for the planned improvements for JMS config like discussed on the mailing list the JMS transport should be refactored for readability.
> I have worked myself into the JMS code and at the start had some problems understanding what happened because of some structures in the code.
> The first thing was JMSTransportBase. Most of the class are methods that do not access any attributes. These methods could be made static and moved to the JMSUtil class. The method isDestinationStyleQueue is the only method that needs an attribute. I think it should have this attribute as a parameter and also be made static and moved to JMSUtils.
> The rest of JMSTransportBase are only holders for attributes that are then accessed from JMSConduit and JMSDestination directly (even without getters). So I think the whole class could be dumped and to attributes should be moved to the subclasses. The readability of JMSConduit and JMSDestination is much better afterwards as the class can be understood in itself.
> The next thing is JMSTransport which is used to feed JMSProviderHub. I think it should be cut down to the callback method connected and be renamed to JMSOnConnectCallBack. The other two methods can be added to the parameters of JMSProviderHub. The advantage is that it is much clearer what JMSProviderHub.connect needs and that connected is a callback that gets called at the end of connect.
> I have already done the refactorings and will attach a patch with them. Checkstyle, PMD and surefire show no problems.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-1773) Refactor JMS transport for readability
and simplicity (patch included)
Posted by "Christian Schneider (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Schneider closed CXF-1773.
------------------------------------
Thanks
> Refactor JMS transport for readability and simplicity (patch included)
> ----------------------------------------------------------------------
>
> Key: CXF-1773
> URL: https://issues.apache.org/jira/browse/CXF-1773
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Affects Versions: 2.1.2
> Reporter: Christian Schneider
> Assignee: Willem Jiang
> Fix For: 2.1.3
>
> Attachments: cxf-1773-refactor-jms.patch
>
>
> In preparation for the planned improvements for JMS config like discussed on the mailing list the JMS transport should be refactored for readability.
> I have worked myself into the JMS code and at the start had some problems understanding what happened because of some structures in the code.
> The first thing was JMSTransportBase. Most of the class are methods that do not access any attributes. These methods could be made static and moved to the JMSUtil class. The method isDestinationStyleQueue is the only method that needs an attribute. I think it should have this attribute as a parameter and also be made static and moved to JMSUtils.
> The rest of JMSTransportBase are only holders for attributes that are then accessed from JMSConduit and JMSDestination directly (even without getters). So I think the whole class could be dumped and to attributes should be moved to the subclasses. The readability of JMSConduit and JMSDestination is much better afterwards as the class can be understood in itself.
> The next thing is JMSTransport which is used to feed JMSProviderHub. I think it should be cut down to the callback method connected and be renamed to JMSOnConnectCallBack. The other two methods can be added to the parameters of JMSProviderHub. The advantage is that it is much clearer what JMSProviderHub.connect needs and that connected is a callback that gets called at the end of connect.
> I have already done the refactorings and will attach a patch with them. Checkstyle, PMD and surefire show no problems.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CXF-1773) Refactor JMS transport for readability
and simplicity (patch included)
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Willem Jiang reassigned CXF-1773:
---------------------------------
Assignee: Willem Jiang
> Refactor JMS transport for readability and simplicity (patch included)
> ----------------------------------------------------------------------
>
> Key: CXF-1773
> URL: https://issues.apache.org/jira/browse/CXF-1773
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Affects Versions: 2.1.2
> Reporter: Christian Schneider
> Assignee: Willem Jiang
> Fix For: 2.1.3
>
> Attachments: cxf-1773-refactor-jms.patch
>
>
> In preparation for the planned improvements for JMS config like discussed on the mailing list the JMS transport should be refactored for readability.
> I have worked myself into the JMS code and at the start had some problems understanding what happened because of some structures in the code.
> The first thing was JMSTransportBase. Most of the class are methods that do not access any attributes. These methods could be made static and moved to the JMSUtil class. The method isDestinationStyleQueue is the only method that needs an attribute. I think it should have this attribute as a parameter and also be made static and moved to JMSUtils.
> The rest of JMSTransportBase are only holders for attributes that are then accessed from JMSConduit and JMSDestination directly (even without getters). So I think the whole class could be dumped and to attributes should be moved to the subclasses. The readability of JMSConduit and JMSDestination is much better afterwards as the class can be understood in itself.
> The next thing is JMSTransport which is used to feed JMSProviderHub. I think it should be cut down to the callback method connected and be renamed to JMSOnConnectCallBack. The other two methods can be added to the parameters of JMSProviderHub. The advantage is that it is much clearer what JMSProviderHub.connect needs and that connected is a callback that gets called at the end of connect.
> I have already done the refactorings and will attach a patch with them. Checkstyle, PMD and surefire show no problems.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1773) Refactor JMS transport for readability
and simplicity (patch included)
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627379#action_12627379 ]
Willem Jiang commented on CXF-1773:
-----------------------------------
Hi Jason,
You point out a key issue of current CXF configuration (we just use jaxb to parser the configuration, the configurations are schema first and not the java code first)
which introduces some limitation :
1. You can't use the property placeholders in your configuration.
2. You can't configure the beans which are just changed some default value, by using the <bean > property style configuration.
Current patch is not cover the issue that you point, but we are discussing in this thread[1] for a new JMS configuration.
[1] http://www.nabble.com/Proposal-for-a-new-JMS-configuration-for-CXF-td19234299.html
Please feel free to add your comments there.
Willem
> Refactor JMS transport for readability and simplicity (patch included)
> ----------------------------------------------------------------------
>
> Key: CXF-1773
> URL: https://issues.apache.org/jira/browse/CXF-1773
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Affects Versions: 2.1.2
> Reporter: Christian Schneider
> Assignee: Willem Jiang
> Fix For: 2.1.3
>
> Attachments: cxf-1773-refactor-jms.patch
>
>
> In preparation for the planned improvements for JMS config like discussed on the mailing list the JMS transport should be refactored for readability.
> I have worked myself into the JMS code and at the start had some problems understanding what happened because of some structures in the code.
> The first thing was JMSTransportBase. Most of the class are methods that do not access any attributes. These methods could be made static and moved to the JMSUtil class. The method isDestinationStyleQueue is the only method that needs an attribute. I think it should have this attribute as a parameter and also be made static and moved to JMSUtils.
> The rest of JMSTransportBase are only holders for attributes that are then accessed from JMSConduit and JMSDestination directly (even without getters). So I think the whole class could be dumped and to attributes should be moved to the subclasses. The readability of JMSConduit and JMSDestination is much better afterwards as the class can be understood in itself.
> The next thing is JMSTransport which is used to feed JMSProviderHub. I think it should be cut down to the callback method connected and be renamed to JMSOnConnectCallBack. The other two methods can be added to the parameters of JMSProviderHub. The advantage is that it is much clearer what JMSProviderHub.connect needs and that connected is a callback that gets called at the end of connect.
> I have already done the refactorings and will attach a patch with them. Checkstyle, PMD and surefire show no problems.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1773) Refactor JMS transport for readability
and simplicity (patch included)
Posted by "Jason Dwyer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627356#action_12627356 ]
Jason Dwyer commented on CXF-1773:
----------------------------------
hi,
i havent had a chance to dig into the patch, so apologies if this is already covered...
recently we were working witht he jms transport, and found a limitation that prevented us from parametizing our spring beans configuration with property placeholders, as it emerged the elements from the configuration were being passed to a jaxb parser rather than through spring, and rather than having the properties replaced, were being passed along to the jaxb deserialisation
if the jms transport is to be refactored, would it be possible to also re-work the spring configuration ( and runtime interpretation ) such that any property placeholders are processed before instantiation of the transports?
from memory, this looked like a fairly big re-working, and our workaround was to write a few wrapper classes that _could_ be parametized, then have those set up the jms transport programatically, but this seemed very much a workaround rather than a permanent solution.
> Refactor JMS transport for readability and simplicity (patch included)
> ----------------------------------------------------------------------
>
> Key: CXF-1773
> URL: https://issues.apache.org/jira/browse/CXF-1773
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Affects Versions: 2.1.2
> Reporter: Christian Schneider
> Assignee: Willem Jiang
> Fix For: 2.1.3
>
> Attachments: cxf-1773-refactor-jms.patch
>
>
> In preparation for the planned improvements for JMS config like discussed on the mailing list the JMS transport should be refactored for readability.
> I have worked myself into the JMS code and at the start had some problems understanding what happened because of some structures in the code.
> The first thing was JMSTransportBase. Most of the class are methods that do not access any attributes. These methods could be made static and moved to the JMSUtil class. The method isDestinationStyleQueue is the only method that needs an attribute. I think it should have this attribute as a parameter and also be made static and moved to JMSUtils.
> The rest of JMSTransportBase are only holders for attributes that are then accessed from JMSConduit and JMSDestination directly (even without getters). So I think the whole class could be dumped and to attributes should be moved to the subclasses. The readability of JMSConduit and JMSDestination is much better afterwards as the class can be understood in itself.
> The next thing is JMSTransport which is used to feed JMSProviderHub. I think it should be cut down to the callback method connected and be renamed to JMSOnConnectCallBack. The other two methods can be added to the parameters of JMSProviderHub. The advantage is that it is much clearer what JMSProviderHub.connect needs and that connected is a callback that gets called at the end of connect.
> I have already done the refactorings and will attach a patch with them. Checkstyle, PMD and surefire show no problems.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1773) Refactor JMS transport for readability
and simplicity (patch included)
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627377#action_12627377 ]
Willem Jiang commented on CXF-1773:
-----------------------------------
Applied patch into the trunk http://svn.apache.org/viewvc?rev=690638&view=rev
and 2.1.x fix branch http://svn.apache.org/viewvc?rev=690841&view=rev
Christian, you can keep upload the refactoring patch to the JIRA,
but if your patch changes the function of the original CXF JMS, please open a new Issue for it.
> Refactor JMS transport for readability and simplicity (patch included)
> ----------------------------------------------------------------------
>
> Key: CXF-1773
> URL: https://issues.apache.org/jira/browse/CXF-1773
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Affects Versions: 2.1.2
> Reporter: Christian Schneider
> Assignee: Willem Jiang
> Fix For: 2.1.3
>
> Attachments: cxf-1773-refactor-jms.patch
>
>
> In preparation for the planned improvements for JMS config like discussed on the mailing list the JMS transport should be refactored for readability.
> I have worked myself into the JMS code and at the start had some problems understanding what happened because of some structures in the code.
> The first thing was JMSTransportBase. Most of the class are methods that do not access any attributes. These methods could be made static and moved to the JMSUtil class. The method isDestinationStyleQueue is the only method that needs an attribute. I think it should have this attribute as a parameter and also be made static and moved to JMSUtils.
> The rest of JMSTransportBase are only holders for attributes that are then accessed from JMSConduit and JMSDestination directly (even without getters). So I think the whole class could be dumped and to attributes should be moved to the subclasses. The readability of JMSConduit and JMSDestination is much better afterwards as the class can be understood in itself.
> The next thing is JMSTransport which is used to feed JMSProviderHub. I think it should be cut down to the callback method connected and be renamed to JMSOnConnectCallBack. The other two methods can be added to the parameters of JMSProviderHub. The advantage is that it is much clearer what JMSProviderHub.connect needs and that connected is a callback that gets called at the end of connect.
> I have already done the refactorings and will attach a patch with them. Checkstyle, PMD and surefire show no problems.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-1773) Refactor JMS transport for readability
and simplicity (patch included)
Posted by "Christian Schneider (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Schneider updated CXF-1773:
-------------------------------------
Attachment: cxf-1773-refactor-jms.patch
Complete patch for this isssue. mvn install runs without any problems. I hope this patch can be commited as I would like to do the first real feature improvements based on this patch.
> Refactor JMS transport for readability and simplicity (patch included)
> ----------------------------------------------------------------------
>
> Key: CXF-1773
> URL: https://issues.apache.org/jira/browse/CXF-1773
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Affects Versions: 2.1.2
> Reporter: Christian Schneider
> Fix For: 2.1.3
>
> Attachments: cxf-1773-refactor-jms.patch
>
>
> In preparation for the planned improvements for JMS config like discussed on the mailing list the JMS transport should be refactored for readability.
> I have worked myself into the JMS code and at the start had some problems understanding what happened because of some structures in the code.
> The first thing was JMSTransportBase. Most of the class are methods that do not access any attributes. These methods could be made static and moved to the JMSUtil class. The method isDestinationStyleQueue is the only method that needs an attribute. I think it should have this attribute as a parameter and also be made static and moved to JMSUtils.
> The rest of JMSTransportBase are only holders for attributes that are then accessed from JMSConduit and JMSDestination directly (even without getters). So I think the whole class could be dumped and to attributes should be moved to the subclasses. The readability of JMSConduit and JMSDestination is much better afterwards as the class can be understood in itself.
> The next thing is JMSTransport which is used to feed JMSProviderHub. I think it should be cut down to the callback method connected and be renamed to JMSOnConnectCallBack. The other two methods can be added to the parameters of JMSProviderHub. The advantage is that it is much clearer what JMSProviderHub.connect needs and that connected is a callback that gets called at the end of connect.
> I have already done the refactorings and will attach a patch with them. Checkstyle, PMD and surefire show no problems.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-1773) Refactor JMS transport for readability
and simplicity (patch included)
Posted by "Christian Schneider (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Schneider updated CXF-1773:
-------------------------------------
Fix Version/s: 2.0.9
> Refactor JMS transport for readability and simplicity (patch included)
> ----------------------------------------------------------------------
>
> Key: CXF-1773
> URL: https://issues.apache.org/jira/browse/CXF-1773
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Affects Versions: 2.1.2
> Reporter: Christian Schneider
> Assignee: Willem Jiang
> Fix For: 2.0.9, 2.1.3
>
> Attachments: cxf-1773-refactor-jms.patch
>
>
> In preparation for the planned improvements for JMS config like discussed on the mailing list the JMS transport should be refactored for readability.
> I have worked myself into the JMS code and at the start had some problems understanding what happened because of some structures in the code.
> The first thing was JMSTransportBase. Most of the class are methods that do not access any attributes. These methods could be made static and moved to the JMSUtil class. The method isDestinationStyleQueue is the only method that needs an attribute. I think it should have this attribute as a parameter and also be made static and moved to JMSUtils.
> The rest of JMSTransportBase are only holders for attributes that are then accessed from JMSConduit and JMSDestination directly (even without getters). So I think the whole class could be dumped and to attributes should be moved to the subclasses. The readability of JMSConduit and JMSDestination is much better afterwards as the class can be understood in itself.
> The next thing is JMSTransport which is used to feed JMSProviderHub. I think it should be cut down to the callback method connected and be renamed to JMSOnConnectCallBack. The other two methods can be added to the parameters of JMSProviderHub. The advantage is that it is much clearer what JMSProviderHub.connect needs and that connected is a callback that gets called at the end of connect.
> I have already done the refactorings and will attach a patch with them. Checkstyle, PMD and surefire show no problems.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1773) Refactor JMS transport for readability
and simplicity (patch included)
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12628586#action_12628586 ]
Willem Jiang commented on CXF-1773:
-----------------------------------
Applied the patch into 2.0.x branch
http://svn.apache.org/viewvc?rev=692365&view=rev
> Refactor JMS transport for readability and simplicity (patch included)
> ----------------------------------------------------------------------
>
> Key: CXF-1773
> URL: https://issues.apache.org/jira/browse/CXF-1773
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Affects Versions: 2.1.2
> Reporter: Christian Schneider
> Assignee: Willem Jiang
> Fix For: 2.1.3
>
> Attachments: cxf-1773-refactor-jms.patch
>
>
> In preparation for the planned improvements for JMS config like discussed on the mailing list the JMS transport should be refactored for readability.
> I have worked myself into the JMS code and at the start had some problems understanding what happened because of some structures in the code.
> The first thing was JMSTransportBase. Most of the class are methods that do not access any attributes. These methods could be made static and moved to the JMSUtil class. The method isDestinationStyleQueue is the only method that needs an attribute. I think it should have this attribute as a parameter and also be made static and moved to JMSUtils.
> The rest of JMSTransportBase are only holders for attributes that are then accessed from JMSConduit and JMSDestination directly (even without getters). So I think the whole class could be dumped and to attributes should be moved to the subclasses. The readability of JMSConduit and JMSDestination is much better afterwards as the class can be understood in itself.
> The next thing is JMSTransport which is used to feed JMSProviderHub. I think it should be cut down to the callback method connected and be renamed to JMSOnConnectCallBack. The other two methods can be added to the parameters of JMSProviderHub. The advantage is that it is much clearer what JMSProviderHub.connect needs and that connected is a callback that gets called at the end of connect.
> I have already done the refactorings and will attach a patch with them. Checkstyle, PMD and surefire show no problems.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-1773) Refactor JMS transport for readability
and simplicity (patch included)
Posted by "Christian Schneider (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627352#action_12627352 ]
Christian Schneider commented on CXF-1773:
------------------------------------------
Thanks for the commit Willem. I have done some more refactorings. Should I open a new Issue or just upload and explain the patch?
> Refactor JMS transport for readability and simplicity (patch included)
> ----------------------------------------------------------------------
>
> Key: CXF-1773
> URL: https://issues.apache.org/jira/browse/CXF-1773
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Affects Versions: 2.1.2
> Reporter: Christian Schneider
> Assignee: Willem Jiang
> Fix For: 2.1.3
>
> Attachments: cxf-1773-refactor-jms.patch
>
>
> In preparation for the planned improvements for JMS config like discussed on the mailing list the JMS transport should be refactored for readability.
> I have worked myself into the JMS code and at the start had some problems understanding what happened because of some structures in the code.
> The first thing was JMSTransportBase. Most of the class are methods that do not access any attributes. These methods could be made static and moved to the JMSUtil class. The method isDestinationStyleQueue is the only method that needs an attribute. I think it should have this attribute as a parameter and also be made static and moved to JMSUtils.
> The rest of JMSTransportBase are only holders for attributes that are then accessed from JMSConduit and JMSDestination directly (even without getters). So I think the whole class could be dumped and to attributes should be moved to the subclasses. The readability of JMSConduit and JMSDestination is much better afterwards as the class can be understood in itself.
> The next thing is JMSTransport which is used to feed JMSProviderHub. I think it should be cut down to the callback method connected and be renamed to JMSOnConnectCallBack. The other two methods can be added to the parameters of JMSProviderHub. The advantage is that it is much clearer what JMSProviderHub.connect needs and that connected is a callback that gets called at the end of connect.
> I have already done the refactorings and will attach a patch with them. Checkstyle, PMD and surefire show no problems.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.