Brad,
I'm 95% sure this is my fault again. :-(
The last snapshot is from the 25th and that did break the List<Object>
stuff. I fixed it yesterday, but didn't deploy a new snapshot. I'm
doing that now, but that will take an hour or so.
Couple notes:
That use of the @ResponseWrapper is not correct. Technically, that
shouldn't work. I'm surprised it does. It should be throwing an
exception. Those annotations are to specify classes that the runtime
can use to "wrap" the parts and hold the other JAXB related annotations.
Basically, in your case, it should point to a class that looks something
like:
@XmlRootElement(......)
... other JAXB annotations ....
class GetAllProductsResponse {
List<ProductSummary> _return;
..getter/setter....
}
The JAX-WS RI runtime requires those wrapper types to work. In your
case, you would first run wsgen on your service class to have it
generate those classes for you. With CXF, you CAN generate those with
the java2wsdl tool with the "-s" flag. However, the runtime should
work without them. (2.0 didn't due to bugs, we're hoping thats fixed in
2.0.1)
If you want a workaround for the July 25th snapshot, there are a couple
options:
1) Add a method like:
void bugHack(ProductSummary foo);
to the service. The ProductSummary object will be found.
2) Follow instructions at:
https://issues.apache.org/jira/browse/CXF-340
to add the class to the context.
3) If other classes in the same package of ProductSummary are found OK as
they are parameters to a different method, you can add a "jaxb.index"
file to the package that just contains the line:
ProductSummary
(unqualified class name)
Either that or wait for the next snapshot. :-)
Dan
On Friday 27 July 2007 16:10, Brad Harper 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.writePart
>s( 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.invokeDestination(
> 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.proces
>s( 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 <[EMAIL PROTECTED]> 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
> > [EMAIL PROTECTED]
> > http://www.dankulp.com/blog
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog
