Dan, A java.lang.reflect.Proxy can only be constructed from interfaces, and those interfaces are available via reflection. As noted in the JavaDoc:
"Since a proxy class implements all of the interfaces specified at its creation, invoking getInterfaces on its Class object will return an array containing the same list of interfaces (in the order specified at its creation)" >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. -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.writeParts( >>> 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.process( >>> 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 > > >
