You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Mike Rheinheimer (JIRA)" <ji...@apache.org> on 2008/04/10 23:46:05 UTC
[jira] Created: (AXIS2-3730) sandesha needs to be able to recognize
jaxws-originated anon operations
sandesha needs to be able to recognize jaxws-originated anon operations
-----------------------------------------------------------------------
Key: AXIS2-3730
URL: https://issues.apache.org/jira/browse/AXIS2-3730
Project: Axis 2.0 (Axis2)
Issue Type: Improvement
Components: jaxws
Reporter: Mike Rheinheimer
>From David Parsons: "in RM I have to assume that an anon operation could be a user
defined operation. As an anonOutIn operation is always added it triggers some extra RM logic which in some cases breaks our .NET interop scenario. My suggestion was to prefix the operations with something so that I can check for these and decide whether they are user defined operations. At the moment I check for operations prefixed with sandesha for example as I know these are RM defined operations. I'm not too bothered what you rename them to as long as that limits a clash with any potential userdefined operations. That way I can check for them in RM."
So, without spending a huge amount of time thinking about it, I simply added a prefix to the "static final" QNames defined in org.apache.axis2.client.ServiceClient. The QName constructor will accept 'null' for the namespaceURI.
http://java.sun.com/j2ee/1.4/docs/api/javax/xml/namespace/QName.html#QName(java.lang.String,%20java.lang.String,%20java.lang.String)
So, is this an acceptable fix? All of the tests passed in my environment, but I'm not convinced this is enough. See patch_candidate01.txt
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-3730) sandesha needs to be able to recognize
jaxws-originated anon operations
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Rheinheimer updated AXIS2-3730:
------------------------------------
Attachment: patch_candidate01.txt
> sandesha needs to be able to recognize jaxws-originated anon operations
> -----------------------------------------------------------------------
>
> Key: AXIS2-3730
> URL: https://issues.apache.org/jira/browse/AXIS2-3730
> Project: Axis 2.0 (Axis2)
> Issue Type: Improvement
> Components: jaxws
> Reporter: Mike Rheinheimer
> Attachments: patch_candidate01.txt
>
>
> From David Parsons: "in RM I have to assume that an anon operation could be a user
> defined operation. As an anonOutIn operation is always added it triggers some extra RM logic which in some cases breaks our .NET interop scenario. My suggestion was to prefix the operations with something so that I can check for these and decide whether they are user defined operations. At the moment I check for operations prefixed with sandesha for example as I know these are RM defined operations. I'm not too bothered what you rename them to as long as that limits a clash with any potential userdefined operations. That way I can check for them in RM."
> So, without spending a huge amount of time thinking about it, I simply added a prefix to the "static final" QNames defined in org.apache.axis2.client.ServiceClient. The QName constructor will accept 'null' for the namespaceURI.
> http://java.sun.com/j2ee/1.4/docs/api/javax/xml/namespace/QName.html#QName(java.lang.String,%20java.lang.String,%20java.lang.String)
> So, is this an acceptable fix? All of the tests passed in my environment, but I'm not convinced this is enough. See patch_candidate01.txt
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3730) sandesha needs to be able to
recognize jaxws-originated anon operations
Posted by "Dave Parsons (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592105#action_12592105 ]
Dave Parsons commented on AXIS2-3730:
-------------------------------------
I have tried the patch and it looks good. I can now build a sandesha2 patch that checks for this namespace when deciding on whether or not the axis operation is user defined.
Dave
> sandesha needs to be able to recognize jaxws-originated anon operations
> -----------------------------------------------------------------------
>
> Key: AXIS2-3730
> URL: https://issues.apache.org/jira/browse/AXIS2-3730
> Project: Axis 2.0 (Axis2)
> Issue Type: Improvement
> Components: jaxws
> Reporter: Mike Rheinheimer
> Attachments: patch_candidate01.txt, patch_candidate02.txt
>
>
> From David Parsons: "in RM I have to assume that an anon operation could be a user
> defined operation. As an anonOutIn operation is always added it triggers some extra RM logic which in some cases breaks our .NET interop scenario. My suggestion was to prefix the operations with something so that I can check for these and decide whether they are user defined operations. At the moment I check for operations prefixed with sandesha for example as I know these are RM defined operations. I'm not too bothered what you rename them to as long as that limits a clash with any potential userdefined operations. That way I can check for them in RM."
> So, without spending a huge amount of time thinking about it, I simply added a prefix to the "static final" QNames defined in org.apache.axis2.client.ServiceClient. The QName constructor will accept 'null' for the namespaceURI.
> http://java.sun.com/j2ee/1.4/docs/api/javax/xml/namespace/QName.html#QName(java.lang.String,%20java.lang.String,%20java.lang.String)
> So, is this an acceptable fix? All of the tests passed in my environment, but I'm not convinced this is enough. See patch_candidate01.txt
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Resolved: (AXIS2-3730) sandesha needs to be able to
recognize jaxws-originated anon operations
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Rheinheimer resolved AXIS2-3730.
-------------------------------------
Resolution: Fixed
resolved: SVN 651306
> sandesha needs to be able to recognize jaxws-originated anon operations
> -----------------------------------------------------------------------
>
> Key: AXIS2-3730
> URL: https://issues.apache.org/jira/browse/AXIS2-3730
> Project: Axis 2.0 (Axis2)
> Issue Type: Improvement
> Components: jaxws
> Reporter: Mike Rheinheimer
> Attachments: patch_candidate01.txt, patch_candidate02.txt
>
>
> From David Parsons: "in RM I have to assume that an anon operation could be a user
> defined operation. As an anonOutIn operation is always added it triggers some extra RM logic which in some cases breaks our .NET interop scenario. My suggestion was to prefix the operations with something so that I can check for these and decide whether they are user defined operations. At the moment I check for operations prefixed with sandesha for example as I know these are RM defined operations. I'm not too bothered what you rename them to as long as that limits a clash with any potential userdefined operations. That way I can check for them in RM."
> So, without spending a huge amount of time thinking about it, I simply added a prefix to the "static final" QNames defined in org.apache.axis2.client.ServiceClient. The QName constructor will accept 'null' for the namespaceURI.
> http://java.sun.com/j2ee/1.4/docs/api/javax/xml/namespace/QName.html#QName(java.lang.String,%20java.lang.String,%20java.lang.String)
> So, is this an acceptable fix? All of the tests passed in my environment, but I'm not convinced this is enough. See patch_candidate01.txt
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3730) sandesha needs to be able to
recognize jaxws-originated anon operations
Posted by "Dustin Amrhein (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587800#action_12587800 ]
Dustin Amrhein commented on AXIS2-3730:
---------------------------------------
It seems like it would be extremely unlikely that a user operation ended up with the same QName, but just in case could we stuff some paramter on the AxisOperation indicating it was not a user operation. The RM code could look for a certain parameter on the AxisOperation that told them not to do this extra logic. Is this a bad idea?
> sandesha needs to be able to recognize jaxws-originated anon operations
> -----------------------------------------------------------------------
>
> Key: AXIS2-3730
> URL: https://issues.apache.org/jira/browse/AXIS2-3730
> Project: Axis 2.0 (Axis2)
> Issue Type: Improvement
> Components: jaxws
> Reporter: Mike Rheinheimer
> Attachments: patch_candidate01.txt
>
>
> From David Parsons: "in RM I have to assume that an anon operation could be a user
> defined operation. As an anonOutIn operation is always added it triggers some extra RM logic which in some cases breaks our .NET interop scenario. My suggestion was to prefix the operations with something so that I can check for these and decide whether they are user defined operations. At the moment I check for operations prefixed with sandesha for example as I know these are RM defined operations. I'm not too bothered what you rename them to as long as that limits a clash with any potential userdefined operations. That way I can check for them in RM."
> So, without spending a huge amount of time thinking about it, I simply added a prefix to the "static final" QNames defined in org.apache.axis2.client.ServiceClient. The QName constructor will accept 'null' for the namespaceURI.
> http://java.sun.com/j2ee/1.4/docs/api/javax/xml/namespace/QName.html#QName(java.lang.String,%20java.lang.String,%20java.lang.String)
> So, is this an acceptable fix? All of the tests passed in my environment, but I'm not convinced this is enough. See patch_candidate01.txt
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Issue Comment Edited: (AXIS2-3730) sandesha needs to be able
to recognize jaxws-originated anon operations
Posted by "Dustin Amrhein (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587800#action_12587800 ]
dustin edited comment on AXIS2-3730 at 4/10/08 3:11 PM:
----------------------------------------------------------------
It seems like it would be extremely unlikely that a user operation ended up with the same QName, but just in case could we stuff some parameter on the AxisOperation indicating it was not a user operation. The RM code could look for a certain parameter on the AxisOperation that told them not to do this extra logic. Is this a bad idea?
was (Author: dustin):
It seems like it would be extremely unlikely that a user operation ended up with the same QName, but just in case could we stuff some paramter on the AxisOperation indicating it was not a user operation. The RM code could look for a certain parameter on the AxisOperation that told them not to do this extra logic. Is this a bad idea?
> sandesha needs to be able to recognize jaxws-originated anon operations
> -----------------------------------------------------------------------
>
> Key: AXIS2-3730
> URL: https://issues.apache.org/jira/browse/AXIS2-3730
> Project: Axis 2.0 (Axis2)
> Issue Type: Improvement
> Components: jaxws
> Reporter: Mike Rheinheimer
> Attachments: patch_candidate01.txt
>
>
> From David Parsons: "in RM I have to assume that an anon operation could be a user
> defined operation. As an anonOutIn operation is always added it triggers some extra RM logic which in some cases breaks our .NET interop scenario. My suggestion was to prefix the operations with something so that I can check for these and decide whether they are user defined operations. At the moment I check for operations prefixed with sandesha for example as I know these are RM defined operations. I'm not too bothered what you rename them to as long as that limits a clash with any potential userdefined operations. That way I can check for them in RM."
> So, without spending a huge amount of time thinking about it, I simply added a prefix to the "static final" QNames defined in org.apache.axis2.client.ServiceClient. The QName constructor will accept 'null' for the namespaceURI.
> http://java.sun.com/j2ee/1.4/docs/api/javax/xml/namespace/QName.html#QName(java.lang.String,%20java.lang.String,%20java.lang.String)
> So, is this an acceptable fix? All of the tests passed in my environment, but I'm not convinced this is enough. See patch_candidate01.txt
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3730) sandesha needs to be able to
recognize jaxws-originated anon operations
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12588657#action_12588657 ]
Mike Rheinheimer commented on AXIS2-3730:
-----------------------------------------
Considering the input from Dustin, David Illsley, and Rich Scheuerle on the mailing list, I think I'll go with the following:
Add "axis2" prefix and "http://org.apache.axis2" namespace to the anon operations in org.apache.axis2.client.ServiceClient AND add a parameter to the operations created in EndpointDescriptionImpl.addAnonymousAxisOperations.
I'll test the full Axis2 bucket, create a patch, post it here in this Jira, have David Parsons review/test, and commit it if no objections come up here or on the mailing list.
> sandesha needs to be able to recognize jaxws-originated anon operations
> -----------------------------------------------------------------------
>
> Key: AXIS2-3730
> URL: https://issues.apache.org/jira/browse/AXIS2-3730
> Project: Axis 2.0 (Axis2)
> Issue Type: Improvement
> Components: jaxws
> Reporter: Mike Rheinheimer
> Attachments: patch_candidate01.txt
>
>
> From David Parsons: "in RM I have to assume that an anon operation could be a user
> defined operation. As an anonOutIn operation is always added it triggers some extra RM logic which in some cases breaks our .NET interop scenario. My suggestion was to prefix the operations with something so that I can check for these and decide whether they are user defined operations. At the moment I check for operations prefixed with sandesha for example as I know these are RM defined operations. I'm not too bothered what you rename them to as long as that limits a clash with any potential userdefined operations. That way I can check for them in RM."
> So, without spending a huge amount of time thinking about it, I simply added a prefix to the "static final" QNames defined in org.apache.axis2.client.ServiceClient. The QName constructor will accept 'null' for the namespaceURI.
> http://java.sun.com/j2ee/1.4/docs/api/javax/xml/namespace/QName.html#QName(java.lang.String,%20java.lang.String,%20java.lang.String)
> So, is this an acceptable fix? All of the tests passed in my environment, but I'm not convinced this is enough. See patch_candidate01.txt
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-3730) sandesha needs to be able to recognize
jaxws-originated anon operations
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Rheinheimer updated AXIS2-3730:
------------------------------------
Attachment: patch_candidate02.txt
David Parsons, please try patch_candidate02.txt. The QName is now has prefix "axis2" and namespaceURI "http://ws.apache.org/namespaces/axis2" from:
kernel:
org.apache.axis2.namespace.Constants.AXIS2_NAMESPACE_PREFIX
org.apache.axis2.namespace.Constants.AXIS2_NAMESPACE_URI
You can and should use those constants to check for the anon operation originator.
> sandesha needs to be able to recognize jaxws-originated anon operations
> -----------------------------------------------------------------------
>
> Key: AXIS2-3730
> URL: https://issues.apache.org/jira/browse/AXIS2-3730
> Project: Axis 2.0 (Axis2)
> Issue Type: Improvement
> Components: jaxws
> Reporter: Mike Rheinheimer
> Attachments: patch_candidate01.txt, patch_candidate02.txt
>
>
> From David Parsons: "in RM I have to assume that an anon operation could be a user
> defined operation. As an anonOutIn operation is always added it triggers some extra RM logic which in some cases breaks our .NET interop scenario. My suggestion was to prefix the operations with something so that I can check for these and decide whether they are user defined operations. At the moment I check for operations prefixed with sandesha for example as I know these are RM defined operations. I'm not too bothered what you rename them to as long as that limits a clash with any potential userdefined operations. That way I can check for them in RM."
> So, without spending a huge amount of time thinking about it, I simply added a prefix to the "static final" QNames defined in org.apache.axis2.client.ServiceClient. The QName constructor will accept 'null' for the namespaceURI.
> http://java.sun.com/j2ee/1.4/docs/api/javax/xml/namespace/QName.html#QName(java.lang.String,%20java.lang.String,%20java.lang.String)
> So, is this an acceptable fix? All of the tests passed in my environment, but I'm not convinced this is enough. See patch_candidate01.txt
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org