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 Dennis Sosnoski <dm...@sosnoski.com> on 2006/09/14 09:28:19 UTC
[Axis2] Options questions
I'm also working on documentation for org.apache.axis2.client.Options,
and again ran into some questions. Here's the list:
1. The COPY_PROPERTIES constant appears to be specifically for use by
org.apache.axis2.context.AbstractContext? Also, the comment for the
setProperties(Map) method discusses this flag, but doesn't actually do
anything relating to it that I can see. I'm thinking the COPY_PROPERTIES
constant should be moved to org.apache.axis2.context.AbstractContext and
all mention of it dropped from Options, since it's just one of many
special options.
2. The getProperties() method isn't clear on what should be expected -
for instance, can the returned map be manipulated directly by the user,
or is it expected to be read-only? The code seems inconsistent, in that
if there *are* any properties defined the map is returned directly, but
if not then a copy of the parent properties map is returned. What is the
intended use of this method?
3. The getRelatesTo(String) method doesn't make any allowance for
multiple RelatesTo items with the same RelationshipType value. I didn't
see anything in the WS-Addressing spec that says the RelationshipType
values have to be unique, so I wonder if we need to worry about this case.
4. The senderTransportProtocol field is only set by a deprecated method
(setTransportInfo()) and doesn't appear to be used for anything, so it
seems confusing to have this exposed as part of the API (via the
getSenderTransportProtocol() method). I suggest deleting the field and
method.
5. You can add ReferenceParameters using the addReferenceParameter()
method - but there's no way to get the values, so WS-Addressing handling
has apparently not been implemented. If we're going to have the add
method present, we should implement handling.
6. Somewhat related to (5), the isManageSessions() and
setManageSessions() methods set a flag which is in turn used by the
addReferenceParameters() methods of
org.apache.axis2.description.OutOnlyAxisOperation and
OutInAxisOperation, but it's somewhat obscure to me what these are
doing. Can anyone give the intended purpose of this manageSessions
property of Options?
7. General comment on the design of this class - we've got a mix of
values that are accessed using specific methods
(get/setSoapVersionURI(), getSetTimeOutInMilliSeconds(), etc.) along
with general properties that are stored in the map. It'd probably be
cleaner and simpler to just store *all* property values in the map,
using the current defined get/set methods simply as convenience methods
to access values with predefined keys ("SOAPVersionURI" and
"TimeOutInMilliSeconds", for instance).
I'll enter Jiras for any appropriate issues, but wanted to first check
the collective wisdom of the list for insights.
- Dennis
--
Dennis M. Sosnoski
SOA, Web Services, and XML
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Options questions
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Hi Dennis ;
> I'm also working on documentation for org.apache.axis2.client.Options,
> and again ran into some questions. Here's the list:
>
> 1. The COPY_PROPERTIES constant appears to be specifically for use by
> org.apache.axis2.context.AbstractContext? Also, the comment for the
> setProperties(Map) method discusses this flag, but doesn't actually do
> anything relating to it that I can see. I'm thinking the
> COPY_PROPERTIES constant should be moved to
> org.apache.axis2.context.AbstractContext and all mention of it dropped
> from Options, since it's just one of many special options.
>
I dont think anyone use this feature and I am +1 on completely remove this.
> 2. The getProperties() method isn't clear on what should be expected -
> for instance, can the returned map be manipulated directly by the
> user, or is it expected to be read-only? The code seems inconsistent,
> in that if there *are* any properties defined the map is returned
> directly, but if not then a copy of the parent properties map is
> returned. What is the intended use of this method?
It should be a read-only map. and which should copy the properties from
the parent and return them too.
>
> 3. The getRelatesTo(String) method doesn't make any allowance for
> multiple RelatesTo items with the same RelationshipType value. I
> didn't see anything in the WS-Addressing spec that says the
> RelationshipType values have to be unique, so I wonder if we need to
> worry about this case.
if that is the case need to create a JIRA :)
>
>
> 4. The senderTransportProtocol field is only set by a deprecated
> method (setTransportInfo()) and doesn't appear to be used for
> anything, so it seems confusing to have this exposed as part of the
> API (via the getSenderTransportProtocol() method). I suggest deleting
> the field and method.
+1
>
> 5. You can add ReferenceParameters using the addReferenceParameter()
> method - but there's no way to get the values, so WS-Addressing
> handling has apparently not been implemented. If we're going to have
> the add method present, we should implement handling.
+1
>
> 6. Somewhat related to (5), the isManageSessions() and
> setManageSessions() methods set a flag which is in turn used by the
> addReferenceParameters() methods of
> org.apache.axis2.description.OutOnlyAxisOperation and
> OutInAxisOperation, but it's somewhat obscure to me what these are
> doing. Can anyone give the intended purpose of this manageSessions
> property of Options?
Say for instance you are invoking a a session aware service (say the
service is deployed in soapsession) , then you need to send the session
related data (service groupId). So when you set this flag one it will
automatically send the service group id back (not only that if there is
cookies it will send them too).
>
> 7. General comment on the design of this class - we've got a mix of
> values that are accessed using specific methods
> (get/setSoapVersionURI(), getSetTimeOutInMilliSeconds(), etc.) along
> with general properties that are stored in the map. It'd probably be
> cleaner and simpler to just store *all* property values in the map,
> using the current defined get/set methods simply as convenience
> methods to access values with predefined keys ("SOAPVersionURI" and
> "TimeOutInMilliSeconds", for instance).
>
> I'll enter Jiras for any appropriate issues, but wanted to first check
> the collective wisdom of the list for insights.
>
+1
> - Dennis
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Options questions
Posted by David Illsley <da...@gmail.com>.
+1 to removal before 1.1
On 16/09/06, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> David Illsley wrote:
> > On 14/09/06, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> >>
> >> 5. You can add ReferenceParameters using the addReferenceParameter()
> >> method - but there's no way to get the values, so WS-Addressing handling
> >> has apparently not been implemented. If we're going to have the add
> >> method present, we should implement handling.
> > Ouch, that's not very good. We have addressing support but the correct
> > and imho best way of adding reference parameters to the outbound
> > message is to add them to the To EPR. As such I'd propose removing
> > this method entirely or at the very least mark it as deprecated and
> > document the fact that is doesn't work
> Anyone object to deleting this method from Options? I left it in
> temporarily, but it sounds like it should go.
>
> - Dennis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Options questions
Posted by Deepal Jayasinghe <de...@opensource.lk>.
> Anyone object to deleting this method from Options? I left it in
> temporarily, but it sounds like it should go.
>
> - Dennis
>
> -
+1 , go ahead and remove that.
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Options questions
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
David Illsley wrote:
> On 14/09/06, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>
>> 5. You can add ReferenceParameters using the addReferenceParameter()
>> method - but there's no way to get the values, so WS-Addressing handling
>> has apparently not been implemented. If we're going to have the add
>> method present, we should implement handling.
> Ouch, that's not very good. We have addressing support but the correct
> and imho best way of adding reference parameters to the outbound
> message is to add them to the To EPR. As such I'd propose removing
> this method entirely or at the very least mark it as deprecated and
> document the fact that is doesn't work
Anyone object to deleting this method from Options? I left it in
temporarily, but it sounds like it should go.
- Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Options questions
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
David Illsley wrote:
> On 14/09/06, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>> ...
>> 3. The getRelatesTo(String) method doesn't make any allowance for
>> multiple RelatesTo items with the same RelationshipType value. I didn't
>> see anything in the WS-Addressing spec that says the RelationshipType
>> values have to be unique, so I wonder if we need to worry about this
>> case.
> I personally haven't seen anyone use custom RelatesTo headers yet
> which is when this would become an issue. Given that and the fact that
> getRelationships() provides a way of getting all the relationships
> which could then be further processed I'd be tempted to document the
> limitation, the fact that you can get all then process yourself and
> add a method which returns an array later if it becomes a common use
> case.
Sounds good to me, so unless anyone objects that's what I'll do.
> ...
>>
>> 5. You can add ReferenceParameters using the addReferenceParameter()
>> method - but there's no way to get the values, so WS-Addressing handling
>> has apparently not been implemented. If we're going to have the add
>> method present, we should implement handling.
> Ouch, that's not very good. We have addressing support but the correct
> and imho best way of adding reference parameters to the outbound
> message is to add them to the To EPR. As such I'd propose removing
> this method entirely or at the very least mark it as deprecated and
> document the fact that is doesn't work
Anyone object to removing this?
>>
>> 7. General comment on the design of this class - we've got a mix of
>> values that are accessed using specific methods
>> (get/setSoapVersionURI(), getSetTimeOutInMilliSeconds(), etc.) along
>> with general properties that are stored in the map. It'd probably be
>> cleaner and simpler to just store *all* property values in the map,
>> using the current defined get/set methods simply as convenience methods
>> to access values with predefined keys ("SOAPVersionURI" and
>> "TimeOutInMilliSeconds", for instance).
> While I agree it would simplfy things a lot and produce a cleaner
> Options class I believe that there is a performance hit to using a Map
> over direct access that we probably want to avoid for a number of the
> properties which are used frequently on the golden path. I've got a
> pretty dumb test attached which shows there is an impact for using a
> map over direct access:
>
> Set using map. 100000000 Iterations. 12718 millis.
> Set direct. 100000000 Iterations. 6844 millis.
> Get using map. 100000000 Iterations. 7438 millis.
> Get direct. 100000000 Iterations. 4828 millis.
>
> but I'm not an expert in performance testing by any stretch of the
> imagination. It might be worth a trade-off but I'd like to see
> relative performance figures for an Axis2 invocation test before
> supporting it.
There's no question that it's somewhat slower to use a map - but I think
these are all values which are only accessed once or twice per request,
so the overhead is negligible. I don't necessarily think it's worth
changing at this point, anyway, though it would make things more consistent.
Thanks for the feedback!
- Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Options questions
Posted by David Illsley <da...@gmail.com>.
Attachment didn't work. Simple perf test at [1]
David
[1] http://people.apache.org/~davidillsley/sample_src/OptionsTest.java
On 14/09/06, David Illsley <da...@gmail.com> wrote:
> On 14/09/06, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> > I'm also working on documentation for org.apache.axis2.client.Options,
> Excellent!
>
> > and again ran into some questions.
> Haven't we all :-(
>
> > Here's the list:
> >
> > 1. The COPY_PROPERTIES constant appears to be specifically for use by
> > org.apache.axis2.context.AbstractContext? Also, the comment for the
> > setProperties(Map) method discusses this flag, but doesn't actually do
> > anything relating to it that I can see. I'm thinking the COPY_PROPERTIES
> > constant should be moved to org.apache.axis2.context.AbstractContext and
> > all mention of it dropped from Options, since it's just one of many
> > special options.
> >
> > 2. The getProperties() method isn't clear on what should be expected -
> > for instance, can the returned map be manipulated directly by the user,
> > or is it expected to be read-only? The code seems inconsistent, in that
> > if there *are* any properties defined the map is returned directly, but
> > if not then a copy of the parent properties map is returned. What is the
> > intended use of this method?
> >
> > 3. The getRelatesTo(String) method doesn't make any allowance for
> > multiple RelatesTo items with the same RelationshipType value. I didn't
> > see anything in the WS-Addressing spec that says the RelationshipType
> > values have to be unique, so I wonder if we need to worry about this case.
> I personally haven't seen anyone use custom RelatesTo headers yet
> which is when this would become an issue. Given that and the fact that
> getRelationships() provides a way of getting all the relationships
> which could then be further processed I'd be tempted to document the
> limitation, the fact that you can get all then process yourself and
> add a method which returns an array later if it becomes a common use
> case.
>
> >
> > 4. The senderTransportProtocol field is only set by a deprecated method
> > (setTransportInfo()) and doesn't appear to be used for anything, so it
> > seems confusing to have this exposed as part of the API (via the
> > getSenderTransportProtocol() method). I suggest deleting the field and
> > method.
> Sounds pretty useless to me.
>
> >
> > 5. You can add ReferenceParameters using the addReferenceParameter()
> > method - but there's no way to get the values, so WS-Addressing handling
> > has apparently not been implemented. If we're going to have the add
> > method present, we should implement handling.
> Ouch, that's not very good. We have addressing support but the correct
> and imho best way of adding reference parameters to the outbound
> message is to add them to the To EPR. As such I'd propose removing
> this method entirely or at the very least mark it as deprecated and
> document the fact that is doesn't work
>
> >
> > 6. Somewhat related to (5), the isManageSessions() and
> > setManageSessions() methods set a flag which is in turn used by the
> > addReferenceParameters() methods of
> > org.apache.axis2.description.OutOnlyAxisOperation and
> > OutInAxisOperation, but it's somewhat obscure to me what these are
> > doing. Can anyone give the intended purpose of this manageSessions
> > property of Options?
> I think it's to do with Axis2 Session Management [1] but I'm not sure
>
> >
> > 7. General comment on the design of this class - we've got a mix of
> > values that are accessed using specific methods
> > (get/setSoapVersionURI(), getSetTimeOutInMilliSeconds(), etc.) along
> > with general properties that are stored in the map. It'd probably be
> > cleaner and simpler to just store *all* property values in the map,
> > using the current defined get/set methods simply as convenience methods
> > to access values with predefined keys ("SOAPVersionURI" and
> > "TimeOutInMilliSeconds", for instance).
> While I agree it would simplfy things a lot and produce a cleaner
> Options class I believe that there is a performance hit to using a Map
> over direct access that we probably want to avoid for a number of the
> properties which are used frequently on the golden path. I've got a
> pretty dumb test attached which shows there is an impact for using a
> map over direct access:
>
> Set using map. 100000000 Iterations. 12718 millis.
> Set direct. 100000000 Iterations. 6844 millis.
> Get using map. 100000000 Iterations. 7438 millis.
> Get direct. 100000000 Iterations. 4828 millis.
>
> but I'm not an expert in performance testing by any stretch of the
> imagination. It might be worth a trade-off but I'd like to see
> relative performance figures for an Axis2 invocation test before
> supporting it.
>
> David
>
> >
> > I'll enter Jiras for any appropriate issues, but wanted to first check
> > the collective wisdom of the list for insights.
> >
> > - Dennis
> >
> > --
> > Dennis M. Sosnoski
> > SOA, Web Services, and XML
> > Training and Consulting
> > http://www.sosnoski.com - http://www.sosnoski.co.nz
> > Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
> [1] http://www.developer.com/services/article.php/3620661
> --
> David Illsley - IBM Web Services Development
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Options questions
Posted by David Illsley <da...@gmail.com>.
On 14/09/06, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> I'm also working on documentation for org.apache.axis2.client.Options,
Excellent!
> and again ran into some questions.
Haven't we all :-(
> Here's the list:
>
> 1. The COPY_PROPERTIES constant appears to be specifically for use by
> org.apache.axis2.context.AbstractContext? Also, the comment for the
> setProperties(Map) method discusses this flag, but doesn't actually do
> anything relating to it that I can see. I'm thinking the COPY_PROPERTIES
> constant should be moved to org.apache.axis2.context.AbstractContext and
> all mention of it dropped from Options, since it's just one of many
> special options.
>
> 2. The getProperties() method isn't clear on what should be expected -
> for instance, can the returned map be manipulated directly by the user,
> or is it expected to be read-only? The code seems inconsistent, in that
> if there *are* any properties defined the map is returned directly, but
> if not then a copy of the parent properties map is returned. What is the
> intended use of this method?
>
> 3. The getRelatesTo(String) method doesn't make any allowance for
> multiple RelatesTo items with the same RelationshipType value. I didn't
> see anything in the WS-Addressing spec that says the RelationshipType
> values have to be unique, so I wonder if we need to worry about this case.
I personally haven't seen anyone use custom RelatesTo headers yet
which is when this would become an issue. Given that and the fact that
getRelationships() provides a way of getting all the relationships
which could then be further processed I'd be tempted to document the
limitation, the fact that you can get all then process yourself and
add a method which returns an array later if it becomes a common use
case.
>
> 4. The senderTransportProtocol field is only set by a deprecated method
> (setTransportInfo()) and doesn't appear to be used for anything, so it
> seems confusing to have this exposed as part of the API (via the
> getSenderTransportProtocol() method). I suggest deleting the field and
> method.
Sounds pretty useless to me.
>
> 5. You can add ReferenceParameters using the addReferenceParameter()
> method - but there's no way to get the values, so WS-Addressing handling
> has apparently not been implemented. If we're going to have the add
> method present, we should implement handling.
Ouch, that's not very good. We have addressing support but the correct
and imho best way of adding reference parameters to the outbound
message is to add them to the To EPR. As such I'd propose removing
this method entirely or at the very least mark it as deprecated and
document the fact that is doesn't work
>
> 6. Somewhat related to (5), the isManageSessions() and
> setManageSessions() methods set a flag which is in turn used by the
> addReferenceParameters() methods of
> org.apache.axis2.description.OutOnlyAxisOperation and
> OutInAxisOperation, but it's somewhat obscure to me what these are
> doing. Can anyone give the intended purpose of this manageSessions
> property of Options?
I think it's to do with Axis2 Session Management [1] but I'm not sure
>
> 7. General comment on the design of this class - we've got a mix of
> values that are accessed using specific methods
> (get/setSoapVersionURI(), getSetTimeOutInMilliSeconds(), etc.) along
> with general properties that are stored in the map. It'd probably be
> cleaner and simpler to just store *all* property values in the map,
> using the current defined get/set methods simply as convenience methods
> to access values with predefined keys ("SOAPVersionURI" and
> "TimeOutInMilliSeconds", for instance).
While I agree it would simplfy things a lot and produce a cleaner
Options class I believe that there is a performance hit to using a Map
over direct access that we probably want to avoid for a number of the
properties which are used frequently on the golden path. I've got a
pretty dumb test attached which shows there is an impact for using a
map over direct access:
Set using map. 100000000 Iterations. 12718 millis.
Set direct. 100000000 Iterations. 6844 millis.
Get using map. 100000000 Iterations. 7438 millis.
Get direct. 100000000 Iterations. 4828 millis.
but I'm not an expert in performance testing by any stretch of the
imagination. It might be worth a trade-off but I'd like to see
relative performance figures for an Axis2 invocation test before
supporting it.
David
>
> I'll enter Jiras for any appropriate issues, but wanted to first check
> the collective wisdom of the list for insights.
>
> - Dennis
>
> --
> Dennis M. Sosnoski
> SOA, Web Services, and XML
> Training and Consulting
> http://www.sosnoski.com - http://www.sosnoski.co.nz
> Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
[1] http://www.developer.com/services/article.php/3620661
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org