cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: org.apache.cxf.interceptor.Fault: Unmarshalling Error : [Lcom.gdservices.service.catalogservice.TpFrame; is not known to this context
Date Tue, 31 Jul 2007 14:41:09 GMT
On Tuesday 31 July 2007 00:31, Brett Wooldridge wrote:
> From the list of interfaces available, you can call getAnnotations()
> just was you would in the case of the original instance.  If for some
> reason you needed to know whether or not it was a proxy, you can call
> Proxy.isProxyClass(instance.getClass()).
>
> If the annotations were on the concrete class and not an interface,
> well then, you're hosed.

And that's part of the issue.....    If the JAX-WS @WebService annotation 
on the Impl specifies things like the Service name, namespace, port 
name, etc... we should use those.     If you create a service using the 
impl but without the transaction stuff, the generated WSDL would look a 
certain way.   However, if you enable the transaction stuff, suddenly 
and for no explainable reason, the wsdl changes and anything that looks 
for that particular service/port may not find it.    That's definitely 
an issue.

The other issue to keep in mind is that the Impl doesn't HAVE to 
implement the service interface.   The @WebService annotation can point 
to the interface that defines the contract, but the impl itself doesn't 
need to implement it.    It can implement a "similar, but possibly 
different" interface that Spring then uses for it's proxy.    I'm not 
saying I advocate this approach.  I think it's silly.  However, it is 
allowable.

Enjoy!
Dan



> -Brett
>
> On 7/30/07 10:29 PM, "Dan Diephouse" <dan@envoisolutions.com> wrote:
> > OK Brad sent me a config sample offline, but I wanted to respond
> > here so it would be properly archived. In essence, when you have a
> > config like this:
> >
> >    <jaxws:endpoint
> >      id="testService"
> >      address="/testService" >
> >                <jaxws:implementor>
> >                       <ref bean="myTestService" />
> >                </jaxws:implementor>
> >    </jaxws:endpoint>
> >    <bean id="myTestService" class="....TestServiceImpl"/>
> >
> > And you combine it with the transaction/AOP stuff from spring,
> > Spring will replace the myTestService with a Java proxy which will
> > take care of the transactions. The downside is that this proxy won't
> > have the annotations on it necessary to create the web service. So
> > CXF won't be able to create the service properly.
> >
> > There is at least one and possibly two the solutions to this. The
> > first one which I know works is to use the <jaxws:server> syntax
> > which allows you to specify the service class to use to construct
> > the wsdl/service interface:
> >
> >
> >    <jaxws:server
> >      id="testService"
> >      address="/testService" serviceClass="...TestServiceImpl">
> >                <jaxws:implementor>
> >                       <ref bean="myTestService" />
> >                </jaxws:implementor>
> >    </jaxws:server>
> >
> > The other possible solution is to tell Spring to use CGLIB bytecode
> > weaving instead of proxies. This can be done by adding the
> > proxy-target-class attribute supposedly (I'm going by the spring
> > docs here, I've never tried it):
> >
> > <aop:config *proxy-target-class="true"*>
> >
> > I think I'll probably add support for users to specify the
> > serviceClass/implementorClass on the <jaxws:endpoint>, but in the
> > meantime at least one of those solutions should work.
> >
> > Cheers,
> >
> > - Dan
> >
> > On 7/30/07, Dan Diephouse <dan@envoisolutions.com> wrote:
> >> Hi Brad,
> >>
> >> Any chance you could at least attach your complete spring
> >> configuration? I think the config you outlined should work, but I
> >> would like to see more. Of course a test case would be welcome too
> >> :-)
> >>
> >> - Dan
> >>
> >> On 7/27/07, Brad Harper <bradharper@gmail.com> wrote:
> >>> The snapshot and adding @ResponseWrappers solved my service issues
> >>> as long
> >>> as I use a client other than CXF.  I've testing utilities I can
> >>> use for now.  My main issue is when I enable my transaction
> >>> advice.  Simply enabling
> >>> this section in my config causes 4 of my 10 services to fail with
> >>> the exception listed below:
> >>>
> >>> <aop:config>
> >>>         <aop:advisor id="serviceTx" advice-ref="txAdvice"
> >>> pointcut="execution(* *..service..*.*(..))" order="0"/>
> >>>     </aop:config>
> >>>
> >>>
> >>>     <tx:advice id="txAdvice">
> >>>         <tx:attributes>
> >>>             <tx:method name="find*" read-only="true"/>
> >>>             <tx:method name="*"/>
> >>>         </tx:attributes>
> >>>     </tx:advice>
> >>>
> >>>
> >>> All of the services are configured identically.... which is
> >>> puzzling why the
> >>> certain 4 fail.
> >>>
> >>> INFO: Interceptor has thrown exception, unwinding now
> >>> org.apache.cxf.interceptor.Fault: Marshalling Error:
> >>> com.gdservices.model.thirdparty.TpMat is not known to this context
> >>>         at org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(
> >>> JAXBEncoderDecoder.java:170)
> >>>         at org.apache.cxf.jaxb.io.DataWriterImpl.write(
> >>> DataWriterImpl.java
> >>>
> >>> :42)
> >>>
> >>>         at
> >>> org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.write
> >>>Parts( AbstractOutDatabindingInterceptor.jav
> >>> a:92)
> >>>         at
> >>> org.apache.cxf.interceptor.BareOutInterceptor.handleMessage(
> >>> BareOutInterceptor.java:68)
> >>>         at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
> >>> PhaseInterceptorChain.java:207)
> >>>         at
> >>> org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage
> >>> (OutgoingChainInterceptor.java:73)
> >>>         at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
> >>> PhaseInterceptorChain.java:207)
> >>>         at
> >>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(
> >>> ChainInitiationObserver.java:73)
> >>>         at
> >>> org.apache.cxf.transport.servlet.ServletDestination.doMessage (
> >>> ServletDestination.java:78)
> >>>         at
> >>> org.apache.cxf.transport.servlet.ServletController.invokeDestinati
> >>>on( ServletController.java:224)
> >>>         at
> >>> org.apache.cxf.transport.servlet.ServletController.invoke(
> >>> ServletController.java:137)
> >>>         at org.apache.cxf.transport.servlet.CXFServlet.invoke (
> >>> CXFServlet.java:271)
> >>>         at org.apache.cxf.transport.servlet.CXFServlet.doPost(
> >>> CXFServlet.java:249)
> >>>         at
> >>> javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at
> >>> javax.servlet.http.HttpServlet.service (HttpServlet.java:803) at
> >>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> >>> ApplicationFilterChain.java:290)
> >>>         at
> >>> org.apache.catalina.core.ApplicationFilterChain.doFilter(
> >>> ApplicationFilterChain.java :206)
> >>>         at org.apache.catalina.core.StandardWrapperValve.invoke(
> >>> StandardWrapperValve.java:230)
> >>>         at org.apache.catalina.core.StandardContextValve.invoke(
> >>> StandardContextValve.java:175)
> >>>         at org.apache.catalina.core.StandardHostValve.invoke(
> >>> StandardHostValve.java:128)
> >>>         at org.apache.catalina.valves.ErrorReportValve.invoke(
> >>> ErrorReportValve.java:104)
> >>>         at org.apache.catalina.core.StandardEngineValve.invoke (
> >>> StandardEngineValve.java:109)
> >>>         at org.apache.catalina.connector.CoyoteAdapter.service(
> >>> CoyoteAdapter.java:261)
> >>>         at org.apache.coyote.http11.Http11Processor.process(
> >>> Http11Processor.java:844)
> >>>         at
> >>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.pr
> >>>ocess( Http11Protocol.java:581)
> >>>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(
> >>> JIoEndpoint.java:447)
> >>>         at java.lang.Thread.run(Thread.java:595)
> >>> Caused by: javax.xml.bind.MarshalException
> >>>
> >>>
> >>> Any suggestions on how to handle my transactions?  Should my
> >>> config above
> >>> work?
> >>>
> >>> One key I've found is for List<Object> return types on my service
> >>> interface,
> >>> the ResponseWrapper classname attribute value needed to be the
> >>> Object type
> >>> of the list... like  below.
> >>>
> >>>     @WebMethod(operationName = "getAllProducts")
> >>>     @ResponseWrapper(targetNamespace = "
> >>> http://catalogService.service.gdservices.com",
> >>>             className = "
> >>> com.gdservices.service.thirdparty.ProductSummary")
> >>>     @WebResult(targetNamespace = "
> >>> http://catalogService.service.gdservices.com",
> >>>             name = "products")
> >>>     List<ProductSummary> getAllProducts(Long userId, Integer
> >>> detailLevel)
> >>> throws ServiceException;
> >>>
> >>> This may be in the docs, but I may have overlooked it... may help
> >>> somebody
> >>> out though.
> >>>
> >>> Thanks for your time.
> >>>
> >>> On 7/27/07, Daniel Kulp < dkulp@apache.org> wrote:
> >>>> On Friday 27 July 2007 11:36, Brad Harper wrote:
> >>>>> CXF:wsdl2java creates the client side version of this object...
> >>>>> what am I missing so that it'll unmarshalled correctly?
> >>>>
> >>>> This is probably also fixed in the latest SNAPSHOT (or by using
> >>>> the wrappers objects).
> >>>>
> >>>> --
> >>>> J. Daniel Kulp
> >>>> Principal Engineer
> >>>> IONA
> >>>> P: 781-902-8727    C: 508-380-7194
> >>>> daniel.kulp@iona.com
> >>>> http://www.dankulp.com/blog
> >>
> >> --
> >> Dan Diephouse
> >> Envoi Solutions
> >> http://envoisolutions.com | http://netzooid.com/blog

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

Mime
View raw message