WARN [ServiceDescription] Guessing fault java type from qn

[sonic-dre]

Hello there.

During the successfull deploying of my ws4ee
Jboss Webservices, I ve got this Warnings for every
Exception I throw in my Service Methods

WARN [ServiceDescription] Guessing fault java type from qname: package.xy.SomeException

I know that Java Exceptions not directly supported in SOAP becouse of interoperability, and Fault Messages are the SOAP Concept to send
Exceptions.

What is the deeper meaning behind this warning,
and how can I prevent this warning, what did I wrong,
and what can I Expect if an Exception is thrown from the Server to the Client?

Thanx for every hint.

dre

[jobor]

I did get the same error : Guessing fault java type from qname: nl.borsoft.www.FacadeException.
It is happening with a standalone java client dynamically looking up the web service endpoint. And if there is a custom type in the element of the WSDL file which can't be mapped to a known java package and class name.
I generated a WSDL file and mapping file with wscompile.

<types>
 <schema targetNamespace="bla bla" etc. etc.
 <complexType name="FacadeException">
 <sequence>
 <element name="message" type="string" nillable="true" />
 </sequence>
 </complexType>
 <element name="FacadeException" type="tns:FacadeException" />
 </schema>
</types>
<portType name="TapeFacadeEndpoint">
 <operation name="getXMLByNumber" parameterOrder="String_1">
 <input message="tns:TapeFacadeEndpoint_getXMLByNumber" />
 <output message="tns:TapeFacadeEndpoint_getXMLByNumberResponse" />
 <fault name="FacadeException" message="tns:FacadeException" />
 </operation>
</portType>
<binding name="TapeFacadeEndpointBinding" type="tns:TapeFacadeEndpoint">
 <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc" />
 <operation name="getXMLByNumber">
 <soap:operation soapAction="" />
 <input>
 <soap:body use="literal" namespace="http://www.borsoft.nl/daisy" />
 </input>
 <output>
 <soap:body use="literal" namespace="http://www.borsoft.nl/daisy" />
 </output>
 <fault name="FacadeException">
 <soap:fault name="FacadeException" use="literal" />
 </fault>
 </operation>
</binding>
<service name="DaisyService">
 <port name="TapeFacadeEndpointPort" binding="tns:TapeFacadeEndpointBinding">
 <soap:address location="REPLACE_WITH_ACTUAL_URL" />
 </port>
</service>

In this case my problem was the same because I published 1 method of my session facade as a web service. My session facade throws a custom FacadeException as an application exception. So my web service interface did the same.

public interface TapeFacadeEndpoint extends Remote {

 public abstract String getXMLByNumber(String number) throws RemoteException, FacadeException;

}

Deploying the web service worked fine. But now the java client wants to make a call. I followed the example of the WIKI with dynamically looking up a web service.

URL url = new URL("http://myhost:8080/DaisyEJB/DaisyService?wsdl");
QName qname = new QName("http://www.borsoft.nl/daisy", "DaisyService");
ServiceFactory factory = ServiceFactory.newInstance();
Service service = factory.createService(url, qname);
TapeFacadeEndpoint endpoint = (TapeFacadeEndpoint) service.getPort(TapeFacadeEndpoint.class);
System.out.println(endpoint.getXMLByNumber(number));

The XML is coming back because I return a XML document in a String variable. But also every time the same warning comes. What I did understand was that it has to do with JAX-RPC not knowing the mapping file.
So I read that JBoss has an alternative to ServiceFactory. And yes they have. The createService method can take more parameters. One of them is an URL to the mapping file. I placed the mapping file on a valid URL location and did the following.

URL url = new URL("http://localhost:8080/DaisyEJB/DaisyService?wsdl");
URL mappingURL = new URL("http://hostname/whatever/mapping.xml");
QName qname = new QName("http://www.borsoft.nl/daisy", "DaisyService");

ServiceFactoryImpl factory = new ServiceFactoryImpl();
Service service = factory.createService(url, mappingURL, null, qname, null);

TapeFacadeEndpoint endpoint = (TapeFacadeEndpoint) service.getPort(TapeFacadeEndpoint.class);
System.out.println(endpoint.getXMLByNumber(number));

Now the call to the endpoint does not complain about not knowing the exception because there is a valid mapping in the mapping file. I did fill 2 parameters with null because of not knowing the exact purpose and guessing that the software was smart enough to react on a null parameter. Yes now you have not a JAX-RPC only dynamic lookup but a JBoss addition on JAX-RPC. But smart ;-)
I'm not very experienced on web services but step by step you learn. I think it is also possible to generate client stubs with wscompile just like wsdl2java from Axis. Then there is a solution of a J2EE client deployed in an EAR file (never done this).

O btw a lot of examples never use the fault element. Mostly I see only input and output and on the remote interface only throwing a RemoteException. If you look at http://www.xmethods.net and try a lot of wsdl files you rarely see the use of the fault element.
So in my mind the thought arises "Am I doing the things the right way with throwing a custom exception?"

You don't have to use the mapping file with dynamic lookup if you don't have custom types in your WSDL.

Johan

[jason.greene]

Exceptions were fixed in 4.0.1RC2, why dont you give that a shot?
The 4.0.1 release is coming very soon.

-Jason

[jason.greene]

Also if you do a cvs checkout of 4.0 branch, there is a test case in the testsuite which demonstrates exceptions.

[thomas.diesler]

cvs co -r Branch_4_0 jboss-4.0
cd jboss-4.0/testsuite
ant -Dtest=org.jboss.test.webservice.exception.ExceptionTestCase one-test

To run all WS tests, use

ant tests-webservice
ant tests-report

[jobor]

First time of doing something with the testsuite. Maybe I'm doing something wrong bu the result of executing the command is

D:\Download\JBoss\jboss-4.0.1RC2-src\testsuite>ant -Dtest=org.jboss.test.webservice.exception.ExceptionTestCase one-test
Buildfile: build.xml
Overriding previous definition of reference to xdoclet.task.classpath

one-test:
[junit] Running org.jboss.test.webservice.exception.ExceptionTestCase
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit] Test org.jboss.test.webservice.exception.ExceptionTestCase FAILED

BUILD SUCCESSFUL
Total time: 3 seconds
D:\Download\JBoss\jboss-4.0.1RC2-src\testsuite>


There is a file called TEST-org.jboss.test.webservice.exception.ExceptionTestCase.xml and a file called TEST-org.jboss.test.webservice.exception.ExceptionTestCase.txt

TEST-org.jboss.test.webservice.exception.ExceptionTestCase.txt

Testsuite: org.jboss.test.webservice.exception.ExceptionTestCase
Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec

Caused an ERROR
org.jboss.test.webservice.exception.ExceptionTestCase
java.lang.ClassNotFoundException: org.jboss.test.webservice.exception.ExceptionTestCase
at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:141)

Johan

[jason.greene]

You need to build the testsuite first, by running the default task.

1. ant
2. ant -Dtest=org.jboss.test.webservice.exception.ExceptionTestCase one-test
3. ant tests-report

[jason.greene]

Actually there is a dependency on the jboss build, so you have to build jboss first so .....

1. cd jboss-4.0 (source checkout)
2. Unix: ./build/build.sh Windows: build\build
3. cd testsuite
4. ant
5. ant -Dtest=org.jboss.test.webservice.exception.ExceptionTestCase one-test
6. ant tests-report

[jobor]

Thanks for the description of the testsuite. That part succeeded.

But the test is a J2EE client. The WARNING at the beginning of this thread was from a standalone client with JAXRPC dynamic proxy invocation.
The normal JAXRPC method is : Service service = factory.createService(url, qname); where you can pass an WSDL url and qname for the service.

But my exception is in a different package than the SEI (standard package) which is no problem with my EJB's. And I just published 1 method of the session facade via a SEI.

When I use the JBoss solution : Service service = factory.createService(url, mappingURL, null, qname, null); then I can pass also an url to the mapping file to generate a dynamic proxy.
The maping file contains a java-xml-type-mapping element where the fully qualified Exception class is mapped to the right namespace and type (or the other way around).
So the JBoss ServiceFactoryImpl class is able to generate a dynamic proxy for a standalone client due to have access to the mapping file.
I don't know if there is a standard way in JAXRPC to have access to the mapping file. I think not because otherwise the existence of ServiceFactoryImpl was of no use.

The key is we don't use J2EE clients but standalone. I wanted to use the using the dynamic proxy or DII approach.
Maybe I should use the static stub approach for a standalone client?

Johan.

[jason.greene]

Yes, jaxrpc-mapping files (jsr 109) was only intended for J2EE clients/servers. If you app is a non-J2EE client, then I would use the JWSDP with generated stubs or JWSDP with DII.

-Jason

[thomas.diesler]

Not many people realize that jboss is sufficiently light weight that it can be used as a container for client apps. As your client evolves it may have needs for a nameing service (JNDI), management (JMX), plugable service architecture, messageing (JMS) etc ...

A minimal jboss installation has indeed a tiny footprint. You could experiment with the minimal configuration and add the JBossWS service.

It maybe the the case that JBossWS client is not sufficiently decoupled from JBossWS server (which requires a servlet container), then we need to fix that.

[jobor]

Thomas,

Are you trying to say that it should be possible to install JBoss as a minimal configuration at the (remote) client?

To be honest, the whole picture of a J2EE client to me is not very clear. I know that a J2EE client has access to all J2EE internal services such as the JNDI ENC etc. But should the J2EE client be run on the same machine as the server or could it be run on a remote client?

By the way the topic of the error in PortProxy is a little mess.
Now I do have a remote standalone client with a dynamic proxy to the SEI. The dynamic proxy is created with the ServiceFactoryImpl class and an URL to the jaxrpc mapping file.
When I run my client the processException method in PortProxy logs the error message before I catch the exception in the client.
Can I suppress this logging?

On the client the custom exception is mapped to the right package and class name :-)

Johan

[thomas.diesler]

Johan,

when the J2EE client looks up the JAXRPC service from JNDI, it provides the properties for the JNDI initial context. Like this

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
java.naming.provider.url=jnp://localhost:1099

The java.naming.provider.url points to the JNDI tree where you deployed your WS4EE client too. So yes, you can have a remote client on a minimal jboss instance with its own JNDI tree. Deploying both WS server/client on the same jboss instance simplifies matters, but may not apply to your overall application design.