Doug,
I did not change my server yet, instead I try using a client but not by
SUN's jaxrpc approach. I used a AXIS client also generated from a WSDL
file. Amazing! It worked!! (could be something wrong in jaxrpc client
stubs generation process?!)
So, my current configuration is:
1)generated a WSDL from a service java interface;
2)fixed the parameter names and labeled as my service WSDL file;
3)regenerated my service from the WSDL file but:
3a)forced my service interface/implementation to be a java.util.Date
avoiding the java.util.Calendar that was throwing a abstract error in
server side (I must confirm!)
3b)in wsdeploy phase, after the compile error in server tie class, I
changed the coded to extract a date from a calendar object, recompile
the class, and repackaged the war completing the web.xml generated.
4)run client code:
4a)with the stubs generated by axis, it works fine (it handles a
Calendar java object instead)
4b)with the stubs generated by SUN's jaxrpc,
1-I tried with Calendar parameter and I got a java null exception!! (no
stubs manipulated, using service interfaces with Calendar):
java.lang.NullPointerException
at
com.sun.xml.rpc.soap.message.SOAPMessageContext.createMessage(SOAPMessageContext.java:109)
2-with the Date parameter, I got this error (no stubs manipulated, using
service interfaces with Date):
java.lang.NoSuchMethodError:
PT.ptinovacao.ngincare.service.NGINCareIF.listDisabledMSISDN(Ljava/lang/String;Ljava/lang/String;Ljava/util/Date;)LPT/ptinovacao/ngincare/service/StatusMSISDN;
Indeed, it's making a little confusion, and I didn't enter in the soap
handlers... So, Doug, do you have any clue for this?
thanks,
Pedro Salazar
On Mon, 2003-01-13 at 19:42, Pedro Salazar wrote:
> Doug,
>
> I tried the approach of using the java.util.Date in my service
> interface/implementation, but it surprises me that when I run my
> *client* it throws a java.lang.AbstractMethodError:
>
> (java.lang.AbstractMethodError
> PT.ptinovacao.ngincare.service.NGINCareIF_Stub.listDisabledMSISDN(Ljava/lang/String;Ljava/lang/String;Ljava/util/Date;)LPT/ptinovacao/ngincare/service/StatusMSISDN;)
>
> What I did:
> ----------
> I modified and compiled the java tie class where the error was happening
> to handle a java.util.Date and not the java.util.Calendar as you may see
> in the following code:
>
> PT.ptinovacao.ngincare.service.StatusMSISDN result =
> ((PT.ptinovacao.ngincare.service.NGINCareIF)
> getTarget()).listDisabledMSISDN(myNGINCareIF_listDisabledMSISDN_RequestStruct.getUser(), myNGINCareIF_listDisabledMSISDN_RequestStruct.getPassword(), myNGINCareIF_listDisabledMSISDN_RequestStruct.getDate().getTime());
>
> I repackage the classes, completing before the incomplete web.xml,
> since that it stopped the generation process (could th process be more
> than that after the compile error?!).
>
> I'm confused now but I will try again the first approach again, and I'll
> give a feedback with a confirmation about my results.
>
> I will be brief in my revaluation.
>
> thanks,
> Pedro Salazar.
>
> On Mon, 2003-01-13 at 19:05, Pedro Salazar wrote:
> > Doug,
> >
> > this exception was thrown in the server side - is logged in tomcat's
> > log.
> >
> > In attach goes my WSDL file that was previously created (generated) by
> > xwrpcc from my service interface but also and *only* modified to fix the
> > parameter names (eg. String_1, String_2, ...). In my service interface
> > the parameter was a java.util.Date object (not a java.util.Calendar).
> >
> > If you need more info about my service, please don't hesitate to ask me
> > (the detailed exception, code, ...).
> >
> > thanks,
> > Pedro Salazar.
> >
> > On Mon, 2003-01-13 at 18:44, Doug Kohlert wrote:
> > > Pedro, is this error on the client or the server? Can you send
> > > me your WSDL file?
> > >
> > > Thanks
> > >
> > > Pedro Salazar wrote:
> > > > Doug,
> > > >
> > > > yes, I *think* that I'm clear about the use of -import (wscompile) in
> > > > conjunction with the model parameter in jaxrpc-ri.xml (wsdeploy), which
> > > > doesn't not affect the generation of stubs for the client (no problem
> > > > using -gen:client against the use of -gen:server). For that acknowledge
> > > > I must express my gratitude to you.
> > > >
> > > > Unfortunately, it raised another problem about the dynamic generation of
> > > > classes from a WSDL file.
> > > > Im my first and old approach (interface->WSDL) I have my interface with
> > > > a method which has a java.util.Date attribute in the signature method
> > > > that was mapped to a "datetime" type in WSDL. Now, I have a WSDL file
> > > > that in wsdeploy process creates a java.util.Calendar java object, which
> > > > will result at run-time say that cannot instantiate a Abstract Class
> > > > (java.util.Calendar) when I run a client invocation! Probably due the
> > > > default constructor politics assumed in RMI for JAXRPC in the Calendar
> > > > java object:
> > > >
> > > > "
> > > > To be supported by JAX-RPC, an application class must conform to the
> > > > following rules:
> > > >
> > > > * It must have a public default constructor.
> > > > * It must not implement (either directly or indirectly) the
> > > > java.rmi.Remote interface.
> > > > * Its fields must be supported JAX-RPC types.
> > > >
> > > > The class may contain public, private, or protected fields. For its
> > > > value to be passed (or returned) during a remote call, a field must meet
> > > > these requirements:
> > > >
> > > > * A public field cannot be final or transient.
> > > > * A non-public field must have corresponding getter and setter
> > > > methods.
> > > > "
> > > >
> > > > If I force to my parameter be a java.util.Date in my service interface I
> > > > will get an error in wsdeploy saying that it cannot cast java.util.Date
> > > > to java.util.Calendar! I'm thinking in editing the generated sources to
> > > > get a date instead the calendar itself but I don't know if it will work
> > > > (well I will try if I can do it).
> > > >
> > > > Could you assist me on that? I will post a message on that in jaxrpc
> > > > list too.
> > > >
> > > > thanks,
> > > > Pedro Salazar.
> > > >
>