Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@xml.apache.org
Importance: Normal
Sensitivity: 
Subject: RE: cvs commit: xml-axis/java/test/MSGDispatch TestService.java
To: axis-dev@xml.apache.org
Message-ID: <OF8170DD40.2424A1C9-ON85256C40.004BA831@boulder.ibm.com>
From: "Rick Rineholt" <rineholt@us.ibm.com>
Date: Thu, 26 Sep 2002 09:59:10 -0400
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii


Glen,
I can't see how it could seem more confusing to the end user experience
with the way it was, case:
I've been working on Axis RPC for sometime and have never needed to list my
methods now I start working with messaging and expect pretty much the same
behavior.  A requirement is added to call a method in my message based
service from another package, I now have list those methods?  Huh? I've
never had to do that with RPC?  The whole "*" is now useless? A new design
criteria comes up and the best solution is for my service exposed class to
extend that some other class. Oh because it so happens to have public
methods that DON'T CONFORM TO AXIS's rules I'm now  mandated to list my
methods? Or if I still want the functionality of not listing them create
some scaffolding class?  WHY?  If I want security and that's my concern
then I would be listing the allowed methods from the beginning.  Let me
please develop/hack without those restriction and when it come time to
deploy to real world and I'm interested in security and what methods are
being called THEN I'll list them; Thank you.

Rick Rineholt
"The truth is out there...  All you need is a better search engine!"

rineholt@us.ibm.com


Glen Daniels <gdaniels@macromedia.com> on 09/26/2002 09:38:28 AM

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

To:    "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
cc:
Subject:    RE: cvs commit: xml-axis/java/test/MSGDispatch TestService.java


In the RPC case, if you specify "*", you still shouldn't have public
methods in your class which you don't want exported - the failure case here
is that people can remotely call dangerous/inappropriate code.  I'm just
saying that the same idea should apply for MSG services with "*", except
that we should notice the non-matching methods right away.

I think the question comes down to this : which is more confusing/difficult
to the user?  To specify "all methods should be exported" and then have
deployment silently ignore non-matching methods for message services, or to
get a deployment failure which makes it very clear that you've allowed more
than is valid in your class signature.  To me, it seems like the former is
more opaque and error-prone - to you, it seems like the latter is annoying.
Maybe we should [VOTE]?

No matter which way this goes, we need to explain VERY CLEARLY in the
documentation and the FAQ how this works.

Incidentally, I think your case below reminds us that we need two further
abilities in WSDD:  1) specify an interface which contains all the allowed
methods in the implementation class, and 2) a "no-superclasses" option.

--Glen

> -----Original Message-----
> From: Rick Rineholt [mailto:rineholt@us.ibm.com]
> Sent: Thursday, September 26, 2002 8:58 AM
> To: axis-dev@xml.apache.org
> Subject: RE: cvs commit: xml-axis/java/test/MSGDispatch
> TestService.java
>
>
>
> Why make it difficult on users!  If I have  on RPC case "*" I'm done
> because all public methods ARE valid signature. If in messge
> provider I
> specify "*" then all methods that make sense  are valid too.
>
> In addition  if I need to inherit from a class that does have
> not have a
> "valid" signature and I specify "*" I get an error that this is not
> a valid signature!!!  NO WAY.
>
> Rick Rineholt
> "The truth is out there...  All you need is a better search engine!"
>
> rineholt@us.ibm.com
>
>
>
> Glen Daniels <gdaniels@macromedia.com> on 09/26/2002 08:41:03 AM
>
> Please respond to axis-dev@xml.apache.org
>
> To:    "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
> cc:
> Subject:    RE: cvs commit: xml-axis/java/test/MSGDispatch
> TestService.java
>
>
>
>
> We're now changing the semantics of what "allowedMethods='*'"
> means - for
> RPC/Doc services, it literally means all public methods should be web
> methods.  Now for Message service it means "just the ones
> that match these
> signatures".  I think that's confusing.  ("why is it saying 'no such
> method'?")
>
> I'm very close to -1 on it.  Why is this a good idea instead of having
> people just specify the legal methods?
>
> --Glen
>
> > -----Original Message-----
> > From: dug@apache.org [mailto:dug@apache.org]
> > Sent: Thursday, September 26, 2002 8:21 AM
> > To: xml-axis-cvs@apache.org
> > Subject: cvs commit: xml-axis/java/test/MSGDispatch TestService.java
> >
> >
> > dug         2002/09/26 05:20:39
> >
> >   Modified:    java/test/MSGDispatch TestService.java
> >   Log:
> >   Expand the test a little to make sure we don't restrict too much.
> >   From the comment in the test:
> >   Adding these dummy methods to make sure that when we deploy this
> >   service using "allowedMethods="*" that we don't barf on them.
> >   This will ensure that people can take classes that have public
> >   methods (some available thru Axis and some not) and still be able
> >   to deploy them.  (We used to throw exceptions about it)
> >
> >   Revision  Changes    Path
> >   1.2       +9 -0
> xml-axis/java/test/MSGDispatch/TestService.java
> >
> >   Index: TestService.java
> >
> ===================================================================
> >   RCS file:
> > /home/cvs/xml-axis/java/test/MSGDispatch/TestService.java,v
> >   retrieving revision 1.1
> >   retrieving revision 1.2
> >   diff -u -r1.1 -r1.2
> >   --- TestService.java      24 Sep 2002 20:45:20 -0000    1.1
> >   +++ TestService.java      26 Sep 2002 12:20:39 -0000    1.2
> >   @@ -75,6 +75,15 @@
> >     * @author Glen Daniels (gdaniels@apache.org)
> >     */
> >    public class TestService {
> >   +    // Adding these dummy methods to make sure that when
> > we deploy this
> >   +    // service using "allowedMethods="*" that we don't
> > barf on them.
> >   +    // This will ensure that people can take classes that
> > have public
> >   +    // methods (some available thru Axis and some not) and
> > still be able
> >   +    // to deploy them.  (We used to throw exceptions about it)
> >   +    public void testBody(int t) {}
> >   +    public void testElement(int t) {}
> >   +    public void testEnvelope(int t) {}
> >   +
> >        public SOAPBodyElement [] testBody(SOAPBodyElement [] bodies)
> >                throws Exception {
> >
> >
> >
> >
> >
>
>
>
>