On Wednesday, November 16, 2011 10:44:21 AM Evangelina Martinez wrote: > > Doesn't look like it's possible. Can I ask what you're trying to > > achieve? > > I'm migrating the functionality that I had in 2.3.1, where if the request > path contains ?wsdl or ?xsd, I would return the corresponding wsdl or xsd. > And for that end I was using the WSDLQueryHandler.
Well, I guess that is what I was wanting more details about. If the service was created from a wsdl/xsd, then the build in stuff should return the wsdl or xsd on the appropriate ?wsdl or ?xsd call. I was curious what issue you had with the built in WSDL handling that required you to subclass it and change the behavior. Dan > > One option really could be to copy the WSDLQueryHandler from 2.4.x, > > modify it > all you want, and register it with 2.5.x. If there is a query handler > registered, it wouldn't get into the interceptor chain. > > Sounds like a good option > > Thanks! > > On Tue, Nov 15, 2011 at 6:06 PM, Daniel Kulp <[email protected]> wrote: > > On Friday, November 11, 2011 11:42:41 AM Evangelina wrote: > > > Hi, > > > > > > I'm upgrading CXF from the version 2.3.1 to 2.5, and I found that > > > that > > > WSDLQueryHandler is not present anymore. I was using the Query > > > handler to generate the WSDL or the XSD. > > > > > > I was trying to use the WSDLGetInterceptor instead, and the > > > > handleMessage of > > > > > the interceptor successfully writes the wsdl in the outMessage of > > > the > > > exchange. But then the interceptor has a finally catch that > > > overrides it and sets it to null. So I'm probably missing > > > something, but where is that value persisted? > > > > Doesn't look like it is. > > > > > Is there a way to retrieve it afterwards? > > > > Doesn't look like it's possible. Can I ask what you're trying to > > achieve? > > > > One option really could be to copy the WSDLQueryHandler from 2.4.x, > > modify it > > all you want, and register it with 2.5.x. If there is a query handler > > registered, it wouldn't get into the interceptor chain. > > > > > > -- > > Daniel Kulp > > [email protected] > > http://dankulp.com/blog > > Talend - http://www.talend.com -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
