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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [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 > >> > >> -- > >> 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 [EMAIL PROTECTED] http://www.dankulp.com/blog
