David Illsley wrote:
On 14/09/06, Dennis Sosnoski <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
