Hi,
you do not need to use the generated SOAPBindingImpl class.You can continue
with your existing class if you change the classname parameter in your
deploy.wsdd file.
----- Original Message -----
From: "James Black" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, October 07, 2002 6:49 PM
Subject: Re: "Chicken-Egg" problem with Java2WSDL/WSDL2Java
> Vishal Mehra wrote:
>
> > Thanks James,
> >
> > Yes, one can provide the business logic either in SOAPBindingStub.java
or
> > SOAPBindingImp.java but this does not solve the problem of moving the
logic
> > from existing java classes to any one of the above classes.
> >
> > Is there an automated way to transform the existing java classes to
> > SOAPBindingImp.java? or an automated way to write wrapper
(SOAPBindingImp)
> > classes on top of existing java classes?
>
> What I do is just have my SOAPBindingImp class just call the original
java
> classes that actually has the logic. So, it just serves as a way to tie
> together many java classes and SOAP.
> As to automation, there is none that I know of, but then, it isn't that
hard
> to just go through the server stubs made by wsdl2java and just have it
return
> what is in your business logic.
>
> For example, if I have in my interface
> public String method1(int somenum, String somestr) throws
> java.rmi.RemoteException;
>
> In the server stub I have
> public String method1(int somenum, String somestr) ... {
> SOAPBindingStub test = new SOAPBindingStub();
> return test.method1(somenum, somestr);
> }
>
> In SOAPBindingStub:
> public String method1(int somenum, String somestr) ... {
> [business logic]
> }
>
> Why put all the business logic in SOAPBindingImp? You should keep logic
in
> the logical class, and just use the various components.
>
> I hope this helps, if not, then I misunderstand what you are asking
about.
>
>
