This maybe a bug in the implementation.
Prashant Kadam wrote:
> Hi,
> I am exactly going through same scenario(SEI-> WSDL -> IF/Impl/Ties/Stubs)
> and same problem(*_exception class generated).
> The initial WSDL generated (by running wscompile with SEI) does not
> match the element names in types section with what I have defined in SEI
> method parameter. So I have to modify WSDL element names to make it easier
> to understand and match with what I have defined in SEI method parameters.
> Than I run wscompile->modified WSDL-> to generate ties/stubs/IF/Impl.
> Everything works fine with this.
>
> 1)Some custom *_exception classes are generated for certain scenerio. More
> on this check below link. And I did not find any solution for this. Dough
> had answer this question.
>
> http://forum.java.sun.com/thread.jspa?threadID=443825&tstart=30
>
> 2) Also one can use "donotoverride" option with wscompile to not generate
> the classes that are already in the classpath. This works but there's still
> one issue. If say I am throwing some exception in my SEI say
> LoginException, the "donnotoverride" feature will still generate
> LoginException class (don't know why only exception classes are still
> generated. I am using both="true" for wscompile).
>
> Prashant.
>
>
> -----Original Message-----
> From: Prashant Kadam [mailto:prashant_sk_at_hotmail.com]
> Sent: Tuesday, May 17, 2005 10:45 AM
> To: users_at_jax-rpc.dev.java.net
> Subject: RE: Re: exception handling
>
>
>
> -----Original Message-----
> From: Ian Jones [mailto:ijones_at_piper-group.com]
> Sent: Tuesday, May 17, 2005 8:25 AM
> To: users_at_jax-rpc.dev.java.net
> Subject: RE: Re: exception handling
>
> Hi Doug,
>
> Yes that has worked! As you said, we were generating the WSDL from the
> SEI and then generating the server artefacts from the WSDL. Now we are
> using just one wscompile command to generate both of these things as
> follows:
>
> C:\jwsdp-1.4\jaxrpc\bin\wscompile.bat -gen:server
> com/piper/trilogiview/control/datamanager/wsdl-gen-config.xml -model
> WEB-INF/DataManager.gz -classpath WEB-INF/classes -nd WEB-INF -keep -d
> WEB-INF/classes -s .
>
> When used like this, and the client stubs have also been generated, the
> exceptions get picked up by the client as expected.
>
> This also seems to solve the problem I mentioned of having to generate
> the server ties into a temporary area. With the original way, wscompile
> generated class files for all aspects of the SEI including the types and
> exception classes. With the new way these are no longer generated. So,
> with the above command the class files are just generated into our
> WEB-INF/classes directory. However, it would also be preferable to keep
> the generated java files which we are doing by using the -keep and -s
> options, as above. But this generates them all in the directory where
> the SEI is defined, i.e. with the IF and Impl classes etc, and this
> becomes quite messy due to the number of classes being generated. In an
> attempt to achieve this I amended the packageName attribute in our
> wsdl-gen-config.xml, but this made little difference. So, is there any
> way of specifying a different package for these to be generated into?
> Or do they have to be in the same package? And, if so, is it still best
> to jar up the server artefacts as we were doing before or to put them in
> a WAR file and use wsdeploy?
>
> Many thanks for your help in solving this problem. Any help on the
> final few queries I have there will be greatly appreciated.
>
> Ian.
>
> -----Original Message-----
> From: Doug Kohlert [mailto:Doug.Kohlert_at_Sun.COM]
> Sent: 16 May 2005 19:19
> To: users_at_jax-rpc.dev.java.net
> Subject: Re: exception handling
>
> Ian,
> I think the problem is that you are trying to create server side
> artifacts
> by first, processing the SEI to create a WSDL and then using the WSDL to
> do
> the server side. I suggest you create the server side artifacts direcly
> from
> the SEI. Please refer to scenario 1 of
> https://jax-rpc.dev.java.net/whitepaper/1.1/index-part2.html
> on how to do this.
>
> Let me know if this works for you.
>
> Ian Jones wrote:
>
>
>>Hi Doug,
>>
>>Once again, many thanks for you help. Here is the information you
>
> asked
>
>>for (By the way, this is all done using JWSDP 1.4):
>>
>>***** WSDL Generation:
>>Contents of wsdl-gen-config.xml:
>><configuration
>> xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/config">
>> <service
>> name="DataManager"
>> targetNamespace="http://www.trilogi.co.uk/datamanager"
>> typeNamespace="http://www.trilogi.co.uk/datamanager"
>> packageName="com.piper.trilogiview.datamanager">
>> <interface
>>name="com.piper.trilogiview.datamanager.DataManagerIF"/>
>> <typeMappingRegistry>
>> <additionalTypes>
>> <class
>>name="com.piper.trilogiview.datamanager.DatabaseType"/>
>> <class
>>name="com.piper.trilogiview.datamanager.GroupDataset"/>
>> </additionalTypes>
>> </typeMappingRegistry>
>> </service>
>></configuration>
>>
>>wscompile command is run from D:\eclipse\workspace\trilogiView as
>>follows:
>>C:\jwsdp-1.4\jaxrpc\bin\wscompile.bat -define -g
>>com/piper/trilogiview/datamanager/wsdl-gen-config.xml -model
>>WEB-INF/DataManager.gz -classpath WEB-INF/classes -nd WEB-INF
>>
>>***** Generating server ties:
>>Contents of tie-gen-config.xml:
>><configuration
>> xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/config">
>> <wsdl
>>location="D:\eclipse\workspace\trilogiView\WEB-INF\DataManager.wsdl"
>>packageName="com.piper.trilogiview.datamanager" />
>></configuration>
>>
>>wscompile command is run in a temporary area, D:\temp, so that they
>
> can
>
>>be built into a jar so that the generated class files don't conflict
>>with the one defining the web service. To be honest, having to do
>
> this
>
>>always feels like something we are doing incorrectly. This may also
>>highlight another problem occurring with the exceptions being created
>
> as
>
>>the generated DataManagerIF.class throws exceptions such as
>>InvalidPasswordException_Exception instead of the specified
>>InvalidPasswordException. So, if the server ties aren't made into a
>
> jar
>
>>file and the DataManagerImpl class is changed then many compilation
>>errors then occur. Perhaps it is something around this area that is
>>causing the problems I am getting? Anyway, here is how the command is
>>run for this:
>>
>>C:\jwsdp-1.4\jaxrpc\bin\wscompile.bat -g -gen:server -f:searchschema
>>
>
> D:\eclipse\workspace\trilogiView\com\piper\trilogiview\datamanager\tie-g
>
>>en-config.xml
>>
>>***** Generating client stubs:
>>Contents of client-stubs.xml:
>><configuration xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/config">
>> <wsdl
>
> location="http://localhost:1332/trilogiView/dataManagerRPC?WSDL"
>
>>packageName="com.piper.datamanagertest.jaxrpc"/>
>></configuration>
>>
>>wscompile command is run from D:\eclipse\workspace\dataManagerTest as
>>follows:
>>C:\jwsdp-1.4\jaxrpc\bin\wscompile.bat -gen:client -keep
>>com/piper/datamanagertest/jaxrpc/client-stubs.xml -f:searchschema
>>
>>As you can see, we're not using the -d option on any of the commands.
>
> As
>
>>for capturing the message on the wire, I'm not entirely sure what you
>>mean. But if you still need this, if you could clarify slightly I
>
> will
>
>>get you that as well.
>>
>>Many thanks,
>>
>>Ian.
>>
>>-----Original Message-----
>>From: Doug Kohlert [mailto:Doug.Kohlert_at_Sun.COM]
>>Sent: 11 May 2005 16:38
>>To: users_at_jax-rpc.dev.java.net
>>Subject: Re: exception handling
>>
>>Ian,
>>Can you send the contents of tie-gen-config.xml, client-stubs.xml,
>>wsdl-gen-config.xml.
>>
>>Also, are you using -d options on any of the commands?
>>What directory are your invoking the commands from?
>>If possible, can you capture the message on the wire and
>>send it to me?
>>
>>
>>Ian Jones wrote:
>>
>>
>>
>>>Hi Doug,
>>>
>>>Thanks for that. However I have tried your suggestion and I still get
>>>the same result. Here are a few more details about what I'm doing -
>>
>>any
>>
>>
>>>more help you can give will be greatly appreciated:
>>>
>>>This is where I throw the exception in my implementation class:
>>>
>>> public String login(String password) throws RemoteException,
>>>InvalidPasswordException {
>>> Environment env = Environment.getInstance();
>>> String dmPassword =
>>>env.getMainConfig().getDataManagerPassword();
>>> if (password.equals(dmPassword)) {
>>> String sessionId = getSessionId();
>>> return sessionId;
>>> } else {
>>> throw new InvalidPasswordException();
>>> }
>>> }
>>>
>>>And here is my latest version of the InvalidPasswordException class,
>>>with your suggested changes:
>>>
>>>public class InvalidPasswordException extends Exception {
>>>
>>> public InvalidPasswordException() {
>>> super("Invalid password");
>>> }
>>>
>>>}
>>>
>>>When the exception gets thrown by the implementation class the server
>>>generates the following stack trace (this is just the first few
>
> lines):
>
>>>
>>>
>>>SEVERE: JAXRPC.TIE.01: caught exception while handling request:
>>>com.piper.trilogiview.datamanager.exceptions.InvalidPasswordException:
>>>Invalid password
>>>com.piper.trilogiview.datamanager.exceptions.InvalidPasswordException:
>>>Invalid password
>>> at
>>>com.piper.trilogiview.datamanager.DataManagerImpl.login(DataManagerImp
>
> l
>
>>.
>>
>>
>>>java:53)
>>> at
>>>com.piper.trilogiview.datamanager.DataManagerIF_Tie.invoke_login(DataM
>
> a
>
>>n
>>
>>
>>>agerIF_Tie.java:248)
>>> at
>>>com.piper.trilogiview.datamanager.DataManagerIF_Tie.processingHook(Dat
>
> a
>
>>M
>>
>>
>>>anagerIF_Tie.java:1445)
>>> at
>>>com.sun.xml.rpc.server.StreamingHandler.handle(StreamingHandler.java:2
>
> 2
>
>>8
>>
>>
>>>)
>>> at
>>>com.sun.xml.rpc.server.http.JAXRPCServletDelegate.doPost(JAXRPCServlet
>
> D
>
>>e
>>
>>
>>>legate.java:316)
>>>
>>>
>>>
>>>Meanwhile the stack trace of the exception caught on the client is
>
> this
>
>>>(again, just the first few lines):
>>>
>>>
>>>
>>>java.rmi.ServerException: JAXRPC.TIE.04: Internal Server Error
>>>(JAXRPC.TIE.01: caught exception while handling request:
>>>com.piper.trilogiview.datamanager.exceptions.InvalidPasswordException:
>>>Invalid password)
>>> at
>>>com.sun.xml.rpc.client.StreamingSender._raiseFault(StreamingSender.jav
>
> a
>
>>:
>>
>>
>>>372)
>>> at
>>>com.sun.xml.rpc.client.StreamingSender._send(StreamingSender.java:224)
>>> at
>>>com.piper.datamanagertest.jaxrpc.DataManagerIF_Stub.login(DataManagerI
>
> F
>
>>_
>>
>>
>>>Stub.java:188)
>>> at
>>>com.piper.datamanagertest.testclient.LoginTest.testInvalidLogin(LoginT
>
> e
>
>>s
>>
>>
>>>t.java:71)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
>
> a
>
>>v
>>
>>
>>>a:39)
>>> at
>>>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
>
> o
>
>>r
>>
>>
>>>Impl.java:25)
>>>
>>>
>>>As you can see the client exception is a ServerException which seems
>
> to
>
>>>reference the InvalidPasswordException within it.
>>>
>>>I'm using wscompile to generate WSDL, server ties and client stubs
>
> from
>
>>>the Java interface. Is there anything I need to add to any of the
>>>config files for these to do with exceptions, as I haven't added
>>>anything at the moment? Or is there a flag I need to specify on
>>>wscompile? Here are the flags I'm using for wscompile at the moment:
>>>
>>>For WSDL generation:
>>>-define -g com/piper/datamanager/wsdl-gen-config.xml -model
>>>WEB-INF/DataManager.gz -classpath WEB-INF/classes -nd WEB-INF
>>>
>>>For generating server ties:
>>>-g -gen:server -f:searchschema
>
> com\piper\datamanager\tie-gen-config.xml
>
>>>For generating client stubs:
>>>-gen:client -keep com/piper/datamanagertest/jaxrpc/client-stubs.xml
>>>-f:searchschema
>>>
>>>Again, many thanks for any further help with this,
>>>
>>>Ian.
>>>
>>>-----Original Message-----
>>>From: Doug Kohlert [mailto:Doug.Kohlert_at_Sun.COM]
>>>Sent: 10 May 2005 18:28
>>>To: users_at_jax-rpc.dev.java.net
>>>Subject: Re: exception handling
>>>
>>>Ian,
>>>InvalidPasswordException_Exception is the proper name on the client.
>>
>>Try
>>
>>
>>>modifying your
>>>exception class on the server to be:
>>>
>>>public class InvalidPasswordException extends Exception {
>>>
>>>public InvalidPasswordException() {
>>>
>>>super("bad password");
>>>
>>>}
>>>
>>>
>>>}
>>>
>>>and see if that works.
>>>
>>>Ian Jones wrote:
>>>
>>>
>>>
>>>
>>>
>>>>All,
>>>>
>>>>I'm attempting to throw a service-specific exception in my JAX-RPC
>
> web
>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>>service. This exception is defined, simply, as follows:
>>>>
>>>>public class InvalidPasswordException extends Exception {
>>>>
>>>>public InvalidPasswordException() {
>>>>
>>>>}
>>>>
>>>>}
>>>>
>>>>and is thrown in the interface of my web service here:
>>>>
>>>>String login(String password) throws RemoteException,
>>>>
>>>>InvalidPasswordException;
>>>>
>>>>I then use wscompile to generate the WSDL, server ties and client
>>>>stubs. However the client stub generated for the exception is called
>>>>InvalidPasswordException_Exception and this is thrown by the login
>>>>method's client stub. Is this what should happen?
>>>>
>>>>In my client I attempt to catch this
>>>>InvalidPasswordException_Exception exception as follows:
>>>>
>>>>try {
>>>>
>>>>client.login("random");
>>>>
>>>>fail("Password was not invalid");
>>>>
>>>>} catch (InvalidPasswordException_Exception e) {
>>>>
>>>>return;
>>>>
>>>>} catch (ServerException e) {
>>>>
>>>>fail(e.getMessage());
>>>>
>>>>} catch (Exception e) {
>>>>
>>>>e.printStackTrace();
>>>>
>>>>fail("failed due to exception " + e.getMessage());
>>>>
>>>>}
>>>>
>>>>In this case the server correctly attempts to throw a new
>>>>InvalidPasswordException, but the client catches a ServerException
>>>>which mentions the InvalidPasswordException within it's message. Is
>>>>this also correct? Shouldn't I just be able to catch an
>>>>InvalidPasswordException as specified by the service's interface?
>>>>
>>>>Many thanks for any help,
>>>>
>>>>Ian Jones
>>>>
>>>>Senior Analyst Developer
>>>>
>>>>Piper Group plc
>>>>
>>>>Email: ijones_at_piper-group.com
>>>>
>>>>Tel: + 44 (0) 1454 284900
>>>>
>>>>Fax: + 44 (0) 1454 284950
>>>>
>>>>www.piper-group.com <http://www.piper-group.com/>
>>>>
>>>>Information contained in this e-mail is intended for the use of the
>>>>addressee only, and is confidential and may be the subject of legal
>>>>professional privilege. Any dissemination, distribution, copying or
>>>>use of this communication without permission of the addressee is
>>>>strictly prohibited. The views expressed in this communication may
>
> not
>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>>necessarily be the views held by Piper Group plc.
>>>>
>>>>
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>>
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>
>
>
--
Doug Kohlert
Java Software Division
Sun Microsystems, Inc.
phone: 503 345-9806