Doug,
sorry to bother you again, but I must try your ultimate approach in
SUN's jaxrpc before try the AXIS.
I have the generated the WSDL file from my service interface.
1)I modified the wsdl to arrange the parameter names;
2)I ran the wscompile, but instead the -import with -keep option to
generate the new service interface, I used the -gen:server with the
-keep option, to generate the ties for the server (I verified!), and I
used my old service interface and implementation (that should be the
same thing as the generated with -import, right?)
3)I ran the wscompile with the -gen:client to generate the stubs for
client invocation.
***PROBLEM***
4) I created a jaxrpc-ri.xml, packaged and run the wsdeploy to generate
my new war file.
When I deploy my web service I noticed that the wsdeploy regenerates all
the ties and the WSDL file based in the reflection method (classes), or
in other words, it redefined the parameters again to String_1 String_2
(I already verified in the new WSDL and in the ties of the new
package!!).
So, I didn't understand your approach... Maybe you have been referred to
it as a way to generated a web service from a WSDL, but always with the
parameter names problem. Do you confirm this issue?
thanks,
Pedro Salazar.
PS. I even try to use the new server ties and client stubs in the
original web service... but no luck:
java.lang.NullPointerException
at
com.sun.xml.rpc.soap.message.SOAPMessageContext.createMessage(SOAPMessageContext.java:109)
...
On Thu, 2003-01-09 at 17:49, Doug Kohlert wrote:
> Pedro, use wscompile -import -model modelfile on a config.xml file
> pointing to a wsdl. File in the details of the generated
> template implementation class.
> Then create the war file with the generated
> classes, model file etc and pass them to wsdeploy as you normally
> would. Make sure you specify the model in the jaxrpc-ri.xml
> file that you pass to wsdeploy.
>
> Axis might be a good bet for you if you are concerned about the
> parameter names.
>
> Pedro Salazar wrote:
> > Greetings,
> >
> > Doug, can you explain how to generate the service interface and the
> > skeleton java files from a WSDL file in sun's jaxrpc development tools?
> > Or maybe I didn't understand the suggested procedures by you! (indeed,
> > its very annoying and dangerous replacing the builders/serializers files
> > in the default generated files by xrpcc).
> >
> > Actually, I'm considering to try the AXIS (apache) to workaround this
> > problem, what do you think about using it? It has the tools to generate
> > stubs and skeletons from a WSDL!
> >
> > Remember, I want to retain the original names of my web service
> > implementation interface for avoiding the confusion of the replaced
> > names (e.g. name1, name2, ... -> String_1, String2, ...).
> >
> > By the way, I'm replying after a long time since the beginning of this
> > thread due some work in other projects that have me very busy. Sorry for
> > that.
> >
> > thanks,
> > Pedro Salazar.
> >
> > On Thu, 2002-12-12 at 18:25, Doug Kohlert wrote:
> >
> >>Pedro, yes you should be able to modify all of the generated classes to
> >>match the WSDL and have it work. I am not aware of anyone doing this but
> >>it should be possible. Another approach is to modify the WSDL and regenerate
> >>the service endpoint interface and the stubbed out implementation class, and
> >>all of the serializer/builder classes. Then it should be possible to modify these
> >>generated classes to use your original service endpoint interface, implementation
> >>class and all of your value type classes. Of course we cannot support you in
> >>taking any of these approaches but in theory it is doable; however you may need
> >>to make quite a few changes in the code and if you miss anything finding the
> >>problem could be difficult.
> >>
> >>The easiest thing to do is to probably create the desired WSDL and generate the
> >>service endpoint interface and stubbed out implementation class, then modify the
> >>stubbed out implementation to act as a proxy or wrapper for your already existing
> >>implementation class. This would not require you to modify any generated code
> >>other than the stubbed out impl class which is expected.
> >>
> >>Pedro Salazar wrote:
> >>
> >>>Doug,
> >>
> >
> >
>
>
> --
> Doug Kohlert
> Java Software Division
> Sun Microsystems, Inc.
> phone: 503 345-9806