[jira] Commented: (AXIS2-4188) JMSSender not extendable

["Ben Reif (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AXIS2-4188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713601#action_12713601 ] 

Ben Reif commented on AXIS2-4188:
---------------------------------

Sorry to reply so late, I got pulled onto some other projects. We just needed a way to include additional custom properties onto the JMSMessage, so I was thinking that simply making those methods protected might be the easiest way to go about it. I do see your point about changing protected methods and potentially breaking other code. Any of the suggested solutions above (putting things into a Map in the MessageContext, or simply refactoring the code to provide extension points) would be an improvement and would probably meet our needs. I'd be happy to contribute a patch, but at the moment I think all we did was just updated the class files and made those methods protected so that we could override them in our implementation. It sounds like that's not the ideal solution though, so we'll probably have to revisit that approach if one of the above suggestions is implemented. 

One thing that could be done (I think this is one option suggested above) is to add a new value in JMSConstants:

public static final String JMS_MESSAGE_PROPERTIES_PREFIX  = "JMS_MESSAGE_PROPERTIES_PREFIX_";

Then in createJMSMessage() do this before returning the JMS Message:

for(String key:msgContext.getProperties().keySet()){
   if(key.startsWith(JMSConstants.JMS_MESSAGE_PROPERTIES_PREFIX)){
      setProperty(message, msgContext, key.replaceFirst(JMSConstants.JMS_MESSAGE_PROPERTIES_PREFIX, ""));
   }
}

By adding a value in the MessageContext that begins with JMS_MESSAGE_PROPERTIES_PREFIX, it will automatically get included in the JMS Message. The bad thing is that you have to iterate through all of the MessageContext Properties, but at least you don't have to make those methods protected. Anyway, just one idea.

> JMSSender not extendable
> ------------------------
>
>                 Key: AXIS2-4188
>                 URL: https://issues.apache.org/jira/browse/AXIS2-4188
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Improvement
>          Components: transports
>    Affects Versions: 1.5, 1.4.1, 1.4
>         Environment: All
>            Reporter: Ben Reif
>            Assignee: Asankha C. Perera
>   Original Estimate: 0.03h
>  Remaining Estimate: 0.03h
>
> We need to extend the org.apache.axis2.transport.jms.JMSSender class so that we can add some custom properties to the JMS Message (most likely via the MessageContext. However, the class is full of private methods which must be copied into a sub-class, and it also uses other classes such as JMSOutTransportInfo that only have package protected constructors. 
> This class is clearly meant to be extended because you can redefine the implementation class in the axis2.xml. But rather then just extending it and overridding a method, you have to jump through hoops and copy a bunch of code to do so. 
> In my opinion this is one of the most frustrating things about using open source code. Many Apache (and Sun projects as well) have a bad habit of coding everything private, package protected, or sometimes even making things final! Most open source projects these days are designed to be extended, but coding things in this way defeats that purpose.  
> Sorry for the long rant and rave, overall I think Axis2 is really great, but could you keep this in mind moving forward :) , and at least maybe make these methods protected in the next release:
> JMSSender - 
> private Message createJMSMessage(MessageContext msgContext, Session session)  throws JMSException {
> }
> private void setProperty(Message message, MessageContext msgCtx, String key){
> }
> private String getProperty(MessageContext mc, String key) {
> }
> private static void handleException(String s) {
> }
> private static void handleException(String s, Exception e) {
> }
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.