I have been working with CXF with JMS transport deployed in a Spring
container over Weblogic application server. I have a service named
"MyHelloWorldImpl.java" which implements "MyHelloWorld.java" interface
with a single method called "hello()". I annotated the
MyHelloWorldImpl.java with the following:
@javax.jws.WebService (serviceName="MyHelloWorld",
endpointInterface="com.gehc.ce.help2services.proxy.MyHelloWorld",
portName="MyHelloWorldPort")
public class MyHelloWorldImpl ...
I have the webservice running in Weblogic server fine. But when I run
the client, I am seeing the following error:
org.apache.cxf.interceptor.Fault: Message part
{http://proxy.help2services.ce.gehc.com/}hello was not recognized.
(Does it exist in service WSDL?)
at
org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLite
ralInInterceptor.java:179)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
hain.java:220)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiati
onObserver.java:78)
at
org.apache.cxf.transport.jms.JMSDestination.onMessage(JMSDestination.jav
a:176)
at
I have the client configured this way:
Public void testHelloWorld() {
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.getInInterceptors().add(new LoggingInInterceptor());
factory.getOutInterceptors().add(new LoggingOutInterceptor());
factory.setServiceClass(MyHelloWorld.class);
factory.setAddress("jms://");
MyHelloWorld hello = (MyHelloWorld) factory.create();
Client client = ClientProxy.getClient(hello);
JMSConduit jmsConduit = (JMSConduit) client.getConduit();
JMSConfiguration config = new JMSConfiguration();
SingleConnectionFactory cf = new SingleConnectionFactory();
cf.setTargetConnectionFactory(createWebLogicConnectionFactory());
config.setTargetDestination(WEBLOGIC_QUEUE_NAME_AUTH);
config.setConnectionFactory(cf);
config.setMessageType("byte");
config.setPubSubDomain(false);
jmsConduit.setJmsConfig(config);
String text = hello.hello();
System.out.println("The returned data is : " + text);
assertTrue(true);
}
The server's endpoint is configured with the following jaxws:endpoint:
<jaxws:endpoint
id="HelloWorldEndPoint"
xmlns:e="http://service.jaxws.cxf.apache.org/endpoint";
xmlns:s="http://service.jaxws.cxf.apache.org/service";
implementor="com.gehc.ce.help2services.proxy.impl.MyHelloWorldImpl"
address="jms://"
endpointName="e:MyHelloWorldPort"
serviceName="s:MyHelloWorld">
<jaxws:features>
<bean
xmlns="http://www.springframework.org/schema/beans";
class="org.apache.cxf.transport.jms.JMSConfigFeature">
<property name="jmsConfig"
ref="jmsMedConfig"/>
</bean>
</jaxws:features>
</jaxws:endpoint>
Can you guys help?
thanks
Sonam Nepali
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron
Mulder
Sent: Wednesday, December 03, 2008 4:10 PM
To: [email protected]
Subject: Re: Exceptions over SOAP
On Wed, Dec 3, 2008 at 5:07 PM, Daniel Kulp <[EMAIL PROTECTED]> wrote:
> Well, the jaxws spec does specifically say: (section 3.7)
>
> The getCause, getLocalizedMessage and getStackTrace getters from
> java.lang.Throwable and the getClass getter from java.lang.Object are
> excluded from the list of getters to be mapped.
Aha! That's the spec reference I was unable to find! Thanks! :) It
does seem to extend a bit beyond that, though -- I tried defining a
separate property get/setNestedException of type Exception (in addition
to the Cause of type Throwable), and that seemed to be omitted too. Oh,
well.
On Wed, Dec 3, 2008 at 5:18 PM, Rao, Sameer V <[EMAIL PROTECTED]> wrote:
> From a technical perspective it would be completely valid expectation
> to be able to return the details of the nested exception.
> However, from a service orientation point of view, wouldn't it be
> preferable to not provide system-specific information/stack trace of
> you java packaging etc?
As it happens, all the usage of this particular service is within one
company. And when something goes wrong, the service developers want the
consumers elsewhere within the company to be able to give them a stack
trace or other information directly, rather than just "please go look in
your logs around 3 PM" or whatever. Plus it seems to help with
debugging during development. So in this case, those concerns outweigh
the pureness of service orientation. I guess you might argue they
should attach an e-mail appender to their log system... Not sure how
that would be received. :)
Thanks,
Aaron
