RE: DO NOT REPLY [Bug 9881] New: - Stub._setProperty is too for giving

[du...@us.ibm.com]

+1!  (to glen's comments)
-Dug


Glen Daniels <gd...@macromedia.com> on 06/16/2002 12:56:36 PM

Please respond to axis-dev@xml.apache.org

To:    "'axis-dev@xml.apache.org'" <ax...@xml.apache.org>
cc:
Subject:    RE: DO NOT REPLY [Bug 9881] New:  -  Stub._setProperty is too
       for  giving




-1!

This seems very bad, and we should take it up with the TCK/JAX-RPC guys.
Does the spec actually mandate this?

One of the whole points of _setProperty() is precisely that you can set
properties that the framework has no clue about, so that they can later be
accessed by your Handlers - this is how a lot of extensibility in Axis
works.

If _setProperty() only accepts "known" properties, then why both with
_setProperty() at all (as opposed to setKnownThing1(), setKnownThing2(),
etc)?

Cheers,
--Glen

> -----Original Message-----
> From: bugzilla@apache.org [mailto:bugzilla@apache.org]
> Sent: Friday, June 14, 2002 3:59 PM
> To: axis-dev@xml.apache.org
> Subject: DO NOT REPLY [Bug 9881] New: - Stub._setProperty is too
> forgiving
>
>
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9881>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> INSERTED IN THE BUG DATABASE.
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9881
>
> Stub._setProperty is too forgiving
>
>            Summary: Stub._setProperty is too forgiving
>            Product: Axis
>            Version: current (nightly)
>           Platform: Other
>         OS/Version: Other
>             Status: NEW
>           Severity: Critical
>           Priority: Other
>          Component: Basic Architecture
>         AssignedTo: axis-dev@xml.apache.org
>         ReportedBy: butek@us.ibm.com
>
>
> The TCK is failing because Stub._setProperty accepts unknown
> properties.
>
> dims just made some fixes so that Call.setProperty doesn't
> accept unknown
> properties.  The same fixes must be done here.  (I'm hoping
> dims can do them
> since he already did the same thing in Call.java!)
>